1 2017-11-06 Robin Morisset <rmorisset@apple.com>
3 CodeBlock::usesOpcode() is dead code
4 https://bugs.webkit.org/show_bug.cgi?id=179316
6 Reviewed by Yusuke Suzuki.
8 Remove CodeBlock::usesOpcode which is dead code
10 * bytecode/CodeBlock.cpp:
11 * bytecode/CodeBlock.h:
13 2017-11-05 Yusuke Suzuki <utatane.tea@gmail.com>
15 JIT call inline caches should cache calls to objects with getCallData/getConstructData traps
16 https://bugs.webkit.org/show_bug.cgi?id=144458
18 Reviewed by Saam Barati.
20 Previously only JSFunction is handled by CallLinkInfo's caching mechanism. This means that
21 InternalFunction calls are not cached and they always go to the slow path. This is not good because
23 1. We need to query getCallData/getConstructData every time in the slow path.
24 2. CallLinkInfo tells nothing in the higher tier JITs.
26 This patch starts handling InternalFunction in CallLinkInfo's caching mechanism. We change InternalFunction
27 to hold pointers to the functions for call and construct. We have new stubs that can call/construct
28 InternalFunction. And we return this code pointer as a result of setup call to use CallLinkInfo mechanism.
30 This patch is critical to optimizing derived Array construction[1] since it starts using CallLinkInfo
31 for InternalFunction. Previously we did not record any information to CallLinkInfo. Except for the
32 case that DFGByteCodeParser figures out InternalFunction constant, we cannot attempt to emit DFG
33 nodes for these InternalFunctions since CallLinkInfo tells us nothing.
35 Attached microbenchmarks show performance improvement.
39 dfg-internal-function-construct 1.6439+-0.0826 ^ 1.2829+-0.0727 ^ definitely 1.2813x faster
40 dfg-internal-function-not-handled-construct 2.1862+-0.1361 2.0696+-0.1201 might be 1.0564x faster
41 dfg-internal-function-not-handled-call 20.7592+-0.9085 19.7369+-0.7921 might be 1.0518x faster
42 dfg-internal-function-call 1.6856+-0.0967 ^ 1.2771+-0.0744 ^ definitely 1.3198x faster
44 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
46 * API/JSCallbackFunction.cpp:
47 (JSC::JSCallbackFunction::JSCallbackFunction):
48 (JSC::JSCallbackFunction::getCallData): Deleted.
49 * API/JSCallbackFunction.h:
50 (JSC::JSCallbackFunction::createStructure):
51 * API/ObjCCallbackFunction.h:
52 (JSC::ObjCCallbackFunction::createStructure):
53 * API/ObjCCallbackFunction.mm:
54 (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
55 (JSC::ObjCCallbackFunction::getCallData): Deleted.
56 (JSC::ObjCCallbackFunction::getConstructData): Deleted.
57 * bytecode/BytecodeDumper.cpp:
58 (JSC::BytecodeDumper<Block>::printCallOp):
59 * bytecode/BytecodeList.json:
60 * bytecode/CallLinkInfo.cpp:
61 (JSC::CallLinkInfo::setCallee):
62 (JSC::CallLinkInfo::callee):
63 (JSC::CallLinkInfo::setLastSeenCallee):
64 (JSC::CallLinkInfo::lastSeenCallee):
65 (JSC::CallLinkInfo::visitWeak):
66 * bytecode/CallLinkInfo.h:
67 * bytecode/CallLinkStatus.cpp:
68 (JSC::CallLinkStatus::computeFromCallLinkInfo):
69 * bytecode/LLIntCallLinkInfo.h:
70 * jit/JITOperations.cpp:
72 (JSC::JITThunks::ctiInternalFunctionCall):
73 (JSC::JITThunks::ctiInternalFunctionConstruct):
77 (JSC::linkPolymorphicCall):
79 * jit/ThunkGenerators.cpp:
80 (JSC::virtualThunkFor):
81 (JSC::nativeForGenerator):
82 (JSC::nativeCallGenerator):
83 (JSC::nativeTailCallGenerator):
84 (JSC::nativeTailCallWithoutSavedTagsGenerator):
85 (JSC::nativeConstructGenerator):
86 (JSC::internalFunctionCallGenerator):
87 (JSC::internalFunctionConstructGenerator):
88 * jit/ThunkGenerators.h:
89 * llint/LLIntSlowPaths.cpp:
90 (JSC::LLInt::setUpCall):
91 * llint/LowLevelInterpreter.asm:
92 * llint/LowLevelInterpreter32_64.asm:
93 * llint/LowLevelInterpreter64.asm:
94 * runtime/ArrayConstructor.cpp:
95 (JSC::ArrayConstructor::ArrayConstructor):
96 (JSC::ArrayConstructor::getConstructData): Deleted.
97 (JSC::ArrayConstructor::getCallData): Deleted.
98 * runtime/ArrayConstructor.h:
99 (JSC::ArrayConstructor::createStructure):
100 * runtime/AsyncFunctionConstructor.cpp:
101 (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
102 (JSC::AsyncFunctionConstructor::finishCreation):
103 (JSC::AsyncFunctionConstructor::getCallData): Deleted.
104 (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
105 * runtime/AsyncFunctionConstructor.h:
106 (JSC::AsyncFunctionConstructor::createStructure):
107 * runtime/AsyncGeneratorFunctionConstructor.cpp:
108 (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor):
109 (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
110 (JSC::AsyncGeneratorFunctionConstructor::getCallData): Deleted.
111 (JSC::AsyncGeneratorFunctionConstructor::getConstructData): Deleted.
112 * runtime/AsyncGeneratorFunctionConstructor.h:
113 (JSC::AsyncGeneratorFunctionConstructor::createStructure):
114 * runtime/BooleanConstructor.cpp:
115 (JSC::callBooleanConstructor):
116 (JSC::BooleanConstructor::BooleanConstructor):
117 (JSC::BooleanConstructor::finishCreation):
118 (JSC::BooleanConstructor::getConstructData): Deleted.
119 (JSC::BooleanConstructor::getCallData): Deleted.
120 * runtime/BooleanConstructor.h:
121 (JSC::BooleanConstructor::createStructure):
122 * runtime/DateConstructor.cpp:
123 (JSC::DateConstructor::DateConstructor):
124 (JSC::DateConstructor::getConstructData): Deleted.
125 (JSC::DateConstructor::getCallData): Deleted.
126 * runtime/DateConstructor.h:
127 (JSC::DateConstructor::createStructure):
129 (JSC::StrictModeTypeErrorFunction::StrictModeTypeErrorFunction):
130 (JSC::StrictModeTypeErrorFunction::createStructure):
131 (JSC::StrictModeTypeErrorFunction::getConstructData): Deleted.
132 (JSC::StrictModeTypeErrorFunction::getCallData): Deleted.
133 * runtime/ErrorConstructor.cpp:
134 (JSC::ErrorConstructor::ErrorConstructor):
135 (JSC::ErrorConstructor::getConstructData): Deleted.
136 (JSC::ErrorConstructor::getCallData): Deleted.
137 * runtime/ErrorConstructor.h:
138 (JSC::ErrorConstructor::createStructure):
139 * runtime/FunctionConstructor.cpp:
140 (JSC::FunctionConstructor::FunctionConstructor):
141 (JSC::FunctionConstructor::finishCreation):
142 (JSC::FunctionConstructor::getConstructData): Deleted.
143 (JSC::FunctionConstructor::getCallData): Deleted.
144 * runtime/FunctionConstructor.h:
145 (JSC::FunctionConstructor::createStructure):
146 * runtime/FunctionPrototype.cpp:
147 (JSC::callFunctionPrototype):
148 (JSC::FunctionPrototype::FunctionPrototype):
149 (JSC::FunctionPrototype::getCallData): Deleted.
150 * runtime/FunctionPrototype.h:
151 (JSC::FunctionPrototype::createStructure):
152 * runtime/GeneratorFunctionConstructor.cpp:
153 (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
154 (JSC::GeneratorFunctionConstructor::finishCreation):
155 (JSC::GeneratorFunctionConstructor::getCallData): Deleted.
156 (JSC::GeneratorFunctionConstructor::getConstructData): Deleted.
157 * runtime/GeneratorFunctionConstructor.h:
158 (JSC::GeneratorFunctionConstructor::createStructure):
159 * runtime/InternalFunction.cpp:
160 (JSC::InternalFunction::InternalFunction):
161 (JSC::InternalFunction::finishCreation):
162 (JSC::InternalFunction::getCallData):
163 (JSC::InternalFunction::getConstructData):
164 * runtime/InternalFunction.h:
165 (JSC::InternalFunction::createStructure):
166 (JSC::InternalFunction::nativeFunctionFor):
167 (JSC::InternalFunction::offsetOfNativeFunctionFor):
168 * runtime/IntlCollatorConstructor.cpp:
169 (JSC::IntlCollatorConstructor::createStructure):
170 (JSC::IntlCollatorConstructor::IntlCollatorConstructor):
171 (JSC::IntlCollatorConstructor::getConstructData): Deleted.
172 (JSC::IntlCollatorConstructor::getCallData): Deleted.
173 * runtime/IntlCollatorConstructor.h:
174 * runtime/IntlDateTimeFormatConstructor.cpp:
175 (JSC::IntlDateTimeFormatConstructor::createStructure):
176 (JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor):
177 (JSC::IntlDateTimeFormatConstructor::getConstructData): Deleted.
178 (JSC::IntlDateTimeFormatConstructor::getCallData): Deleted.
179 * runtime/IntlDateTimeFormatConstructor.h:
180 * runtime/IntlNumberFormatConstructor.cpp:
181 (JSC::IntlNumberFormatConstructor::createStructure):
182 (JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor):
183 (JSC::IntlNumberFormatConstructor::getConstructData): Deleted.
184 (JSC::IntlNumberFormatConstructor::getCallData): Deleted.
185 * runtime/IntlNumberFormatConstructor.h:
186 * runtime/JSArrayBufferConstructor.cpp:
187 (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
188 (JSC::JSArrayBufferConstructor::createStructure):
189 (JSC::JSArrayBufferConstructor::getConstructData): Deleted.
190 (JSC::JSArrayBufferConstructor::getCallData): Deleted.
191 * runtime/JSArrayBufferConstructor.h:
192 * runtime/JSGenericTypedArrayViewConstructor.h:
193 * runtime/JSGenericTypedArrayViewConstructorInlines.h:
194 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::JSGenericTypedArrayViewConstructor):
195 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::createStructure):
196 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getConstructData): Deleted.
197 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData): Deleted.
198 * runtime/JSInternalPromiseConstructor.cpp:
199 (JSC::JSInternalPromiseConstructor::createStructure):
200 (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
201 (JSC::JSInternalPromiseConstructor::getConstructData): Deleted.
202 (JSC::JSInternalPromiseConstructor::getCallData): Deleted.
203 * runtime/JSInternalPromiseConstructor.h:
204 * runtime/JSPromiseConstructor.cpp:
205 (JSC::JSPromiseConstructor::createStructure):
206 (JSC::JSPromiseConstructor::JSPromiseConstructor):
207 (JSC::JSPromiseConstructor::getConstructData): Deleted.
208 (JSC::JSPromiseConstructor::getCallData): Deleted.
209 * runtime/JSPromiseConstructor.h:
211 * runtime/JSTypedArrayViewConstructor.cpp:
212 (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
213 (JSC::JSTypedArrayViewConstructor::createStructure):
214 (JSC::JSTypedArrayViewConstructor::getConstructData): Deleted.
215 (JSC::JSTypedArrayViewConstructor::getCallData): Deleted.
216 * runtime/JSTypedArrayViewConstructor.h:
217 * runtime/MapConstructor.cpp:
218 (JSC::MapConstructor::MapConstructor):
219 (JSC::MapConstructor::getConstructData): Deleted.
220 (JSC::MapConstructor::getCallData): Deleted.
221 * runtime/MapConstructor.h:
222 (JSC::MapConstructor::createStructure):
223 (JSC::MapConstructor::MapConstructor): Deleted.
224 * runtime/NativeErrorConstructor.cpp:
225 (JSC::NativeErrorConstructor::NativeErrorConstructor):
226 (JSC::NativeErrorConstructor::getConstructData): Deleted.
227 (JSC::NativeErrorConstructor::getCallData): Deleted.
228 * runtime/NativeErrorConstructor.h:
229 (JSC::NativeErrorConstructor::createStructure):
230 * runtime/NullGetterFunction.cpp:
231 (JSC::NullGetterFunction::NullGetterFunction):
232 (JSC::NullGetterFunction::getCallData): Deleted.
233 (JSC::NullGetterFunction::getConstructData): Deleted.
234 * runtime/NullGetterFunction.h:
235 (JSC::NullGetterFunction::createStructure):
236 (JSC::NullGetterFunction::NullGetterFunction): Deleted.
237 * runtime/NullSetterFunction.cpp:
238 (JSC::NullSetterFunction::NullSetterFunction):
239 (JSC::NullSetterFunction::getCallData): Deleted.
240 (JSC::NullSetterFunction::getConstructData): Deleted.
241 * runtime/NullSetterFunction.h:
242 (JSC::NullSetterFunction::createStructure):
243 (JSC::NullSetterFunction::NullSetterFunction): Deleted.
244 * runtime/NumberConstructor.cpp:
245 (JSC::NumberConstructor::NumberConstructor):
246 (JSC::constructNumberConstructor):
247 (JSC::constructWithNumberConstructor): Deleted.
248 (JSC::NumberConstructor::getConstructData): Deleted.
249 (JSC::NumberConstructor::getCallData): Deleted.
250 * runtime/NumberConstructor.h:
251 (JSC::NumberConstructor::createStructure):
252 * runtime/ObjectConstructor.cpp:
253 (JSC::ObjectConstructor::ObjectConstructor):
254 (JSC::ObjectConstructor::getConstructData): Deleted.
255 (JSC::ObjectConstructor::getCallData): Deleted.
256 * runtime/ObjectConstructor.h:
257 (JSC::ObjectConstructor::createStructure):
258 * runtime/ProxyConstructor.cpp:
259 (JSC::ProxyConstructor::ProxyConstructor):
260 (JSC::ProxyConstructor::getConstructData): Deleted.
261 (JSC::ProxyConstructor::getCallData): Deleted.
262 * runtime/ProxyConstructor.h:
263 (JSC::ProxyConstructor::createStructure):
264 * runtime/ProxyRevoke.cpp:
265 (JSC::ProxyRevoke::ProxyRevoke):
266 (JSC::ProxyRevoke::getCallData): Deleted.
267 * runtime/ProxyRevoke.h:
268 (JSC::ProxyRevoke::createStructure):
269 * runtime/RegExpConstructor.cpp:
270 (JSC::RegExpConstructor::RegExpConstructor):
271 (JSC::RegExpConstructor::getConstructData): Deleted.
272 (JSC::RegExpConstructor::getCallData): Deleted.
273 * runtime/RegExpConstructor.h:
274 (JSC::RegExpConstructor::createStructure):
275 * runtime/SetConstructor.cpp:
276 (JSC::SetConstructor::SetConstructor):
277 (JSC::SetConstructor::getConstructData): Deleted.
278 (JSC::SetConstructor::getCallData): Deleted.
279 * runtime/SetConstructor.h:
280 (JSC::SetConstructor::createStructure):
281 (JSC::SetConstructor::SetConstructor): Deleted.
282 * runtime/StringConstructor.cpp:
283 (JSC::StringConstructor::StringConstructor):
284 (JSC::StringConstructor::getConstructData): Deleted.
285 (JSC::StringConstructor::getCallData): Deleted.
286 * runtime/StringConstructor.h:
287 (JSC::StringConstructor::createStructure):
288 * runtime/SymbolConstructor.cpp:
289 (JSC::SymbolConstructor::SymbolConstructor):
290 (JSC::SymbolConstructor::getConstructData): Deleted.
291 (JSC::SymbolConstructor::getCallData): Deleted.
292 * runtime/SymbolConstructor.h:
293 (JSC::SymbolConstructor::createStructure):
296 (JSC::VM::getCTIInternalFunctionTrampolineFor):
298 * runtime/WeakMapConstructor.cpp:
299 (JSC::WeakMapConstructor::WeakMapConstructor):
300 (JSC::WeakMapConstructor::getConstructData): Deleted.
301 (JSC::WeakMapConstructor::getCallData): Deleted.
302 * runtime/WeakMapConstructor.h:
303 (JSC::WeakMapConstructor::createStructure):
304 (JSC::WeakMapConstructor::WeakMapConstructor): Deleted.
305 * runtime/WeakSetConstructor.cpp:
306 (JSC::WeakSetConstructor::WeakSetConstructor):
307 (JSC::WeakSetConstructor::getConstructData): Deleted.
308 (JSC::WeakSetConstructor::getCallData): Deleted.
309 * runtime/WeakSetConstructor.h:
310 (JSC::WeakSetConstructor::createStructure):
311 (JSC::WeakSetConstructor::WeakSetConstructor): Deleted.
312 * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
313 (JSC::WebAssemblyCompileErrorConstructor::createStructure):
314 (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
315 (JSC::WebAssemblyCompileErrorConstructor::getConstructData): Deleted.
316 (JSC::WebAssemblyCompileErrorConstructor::getCallData): Deleted.
317 * wasm/js/WebAssemblyCompileErrorConstructor.h:
318 * wasm/js/WebAssemblyInstanceConstructor.cpp:
319 (JSC::WebAssemblyInstanceConstructor::createStructure):
320 (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
321 (JSC::WebAssemblyInstanceConstructor::getConstructData): Deleted.
322 (JSC::WebAssemblyInstanceConstructor::getCallData): Deleted.
323 * wasm/js/WebAssemblyInstanceConstructor.h:
324 * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
325 (JSC::WebAssemblyLinkErrorConstructor::createStructure):
326 (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
327 (JSC::WebAssemblyLinkErrorConstructor::getConstructData): Deleted.
328 (JSC::WebAssemblyLinkErrorConstructor::getCallData): Deleted.
329 * wasm/js/WebAssemblyLinkErrorConstructor.h:
330 * wasm/js/WebAssemblyMemoryConstructor.cpp:
331 (JSC::WebAssemblyMemoryConstructor::createStructure):
332 (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
333 (JSC::WebAssemblyMemoryConstructor::getConstructData): Deleted.
334 (JSC::WebAssemblyMemoryConstructor::getCallData): Deleted.
335 * wasm/js/WebAssemblyMemoryConstructor.h:
336 * wasm/js/WebAssemblyModuleConstructor.cpp:
337 (JSC::WebAssemblyModuleConstructor::createStructure):
338 (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
339 (JSC::WebAssemblyModuleConstructor::getConstructData): Deleted.
340 (JSC::WebAssemblyModuleConstructor::getCallData): Deleted.
341 * wasm/js/WebAssemblyModuleConstructor.h:
342 * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
343 (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
344 (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
345 (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData): Deleted.
346 (JSC::WebAssemblyRuntimeErrorConstructor::getCallData): Deleted.
347 * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
348 * wasm/js/WebAssemblyTableConstructor.cpp:
349 (JSC::WebAssemblyTableConstructor::createStructure):
350 (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
351 (JSC::WebAssemblyTableConstructor::getConstructData): Deleted.
352 (JSC::WebAssemblyTableConstructor::getCallData): Deleted.
353 * wasm/js/WebAssemblyTableConstructor.h:
355 2017-11-03 Michael Saboff <msaboff@apple.com>
357 The Abstract Interpreter needs to change similar to clobberize() in r224366
358 https://bugs.webkit.org/show_bug.cgi?id=179267
360 Reviewed by Saam Barati.
362 Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
363 cases in the abstract interpreter to match what was done for r224366.
365 * dfg/DFGAbstractInterpreterInlines.h:
366 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
368 2017-11-03 Keith Miller <keith_miller@apple.com>
370 PutProperytSlot should inform the IC about the property before effects.
371 https://bugs.webkit.org/show_bug.cgi?id=179262
373 Reviewed by Mark Lam.
375 This patch fixes an issue where we choose to cache setters based on
376 incorrect information. If we did so we might end up OSR exiting
377 more than we would otherwise need to. The new model is that the
378 PutPropertySlot should inform the IC of what the property looked
379 like before any potential side effects might have occurred.
381 * runtime/JSObject.cpp:
382 (JSC::JSObject::putInlineSlow):
386 2017-11-03 Mark Lam <mark.lam@apple.com>
388 CachedCall (and its clients) needs overflow checks.
389 https://bugs.webkit.org/show_bug.cgi?id=179185
391 Reviewed by JF Bastien.
393 * interpreter/CachedCall.h:
394 (JSC::CachedCall::CachedCall):
395 (JSC::CachedCall::hasOverflowedArguments):
397 (JSC::MarkedArgumentBuffer::clear):
398 * runtime/StringPrototype.cpp:
399 (JSC::replaceUsingRegExpSearch):
401 2017-11-03 Devin Rousso <webkit@devinrousso.com>
403 Web Inspector: Canvas2D Profiling: highlight expensive context commands in the captured command log
404 https://bugs.webkit.org/show_bug.cgi?id=178302
405 <rdar://problem/33158849>
407 Reviewed by Brian Burg.
409 * inspector/protocol/Recording.json:
410 Add `duration` to each Frame that represents the total time of all the recorded actions.
412 2017-11-02 Devin Rousso <webkit@devinrousso.com>
414 Web Inspector: Canvas Tab: show supported GL extensions for selected canvas
415 https://bugs.webkit.org/show_bug.cgi?id=179070
416 <rdar://problem/35278276>
418 Reviewed by Brian Burg.
420 * inspector/protocol/Canvas.json:
421 Add `extensionEnabled` event that is fired each time `getExtension` is called with a
422 different string on a WebGL context.
424 2017-11-02 Joseph Pecoraro <pecoraro@apple.com>
426 Make ServiceWorker a Remote Inspector debuggable target
427 https://bugs.webkit.org/show_bug.cgi?id=179043
428 <rdar://problem/34126008>
430 Reviewed by Brian Burg.
432 * inspector/remote/RemoteControllableTarget.h:
433 * inspector/remote/RemoteInspectionTarget.h:
434 * inspector/remote/RemoteInspectorConstants.h:
435 Include a new ServiceWorker remote inspector target type.
437 * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
438 (Inspector::RemoteInspector::listingForInspectionTarget const):
439 Implement listing for a ServiceWorker to include a URL like a page.
441 * inspector/remote/glib/RemoteInspectorGlib.cpp:
442 (Inspector::RemoteInspector::listingForInspectionTarget const):
443 Bail for ServiceWorker support in glib. They will need to implement their support.
445 2017-11-02 Michael Saboff <msaboff@apple.com>
447 DFG needs to handle code motion of code in for..in loop bodies
448 https://bugs.webkit.org/show_bug.cgi?id=179212
450 Reviewed by Keith Miller.
452 The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
453 make calls with side effects. Updated clobberize() for those nodes to take that into account.
455 * dfg/DFGClobberize.h:
456 (JSC::DFG::clobberize):
458 2017-11-02 Joseph Pecoraro <pecoraro@apple.com>
460 Inspector should display service worker served responses properly
461 https://bugs.webkit.org/show_bug.cgi?id=178597
462 <rdar://problem/35186111>
464 Reviewed by Brian Burg.
466 * inspector/protocol/Network.json:
467 Expose a new "service-worker" response source.
469 2017-11-02 Filip Pizlo <fpizlo@apple.com>
471 AI does not correctly model the clobber case of ArithClz32
472 https://bugs.webkit.org/show_bug.cgi?id=179188
474 Reviewed by Michael Saboff.
476 The non-Int32 case clobbers the world because it may call valueOf.
478 * dfg/DFGAbstractInterpreterInlines.h:
479 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
481 2017-11-02 Yusuke Suzuki <utatane.tea@gmail.com>
483 Unreviewed, release throw scope
484 https://bugs.webkit.org/show_bug.cgi?id=178726
486 * dfg/DFGOperations.cpp:
488 2017-11-02 Frederic Wang <fwang@igalia.com>
490 Add references to bug 179167 in FIXME comments
491 https://bugs.webkit.org/show_bug.cgi?id=179168
493 Reviewed by Daniel Bates.
495 * Configurations/FeatureDefines.xcconfig:
497 2017-11-01 Jeremy Jones <jeremyj@apple.com>
499 Implement WKFullscreenWindowController for iOS.
500 https://bugs.webkit.org/show_bug.cgi?id=178924
501 rdar://problem/34697120
503 Reviewed by Simon Fraser.
505 Enable ENABLE_FULLSCREEN_API for iOS.
507 * Configurations/FeatureDefines.xcconfig:
509 2017-11-01 Mark Lam <mark.lam@apple.com>
511 Add support to throw OOM if MarkedArgumentBuffer may overflow.
512 https://bugs.webkit.org/show_bug.cgi?id=179092
513 <rdar://problem/35116160>
515 Reviewed by Saam Barati.
517 The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long
518 time, which renders it unsuitable for automated tests. Instead, I've run a
519 test manually to verify that an OutOfMemoryError will be thrown when an overflow
522 The MarkedArgumentBuffer's destructor will now assert that the client has indeed
523 checked for an overflow after invoking methods that may result in an overflow i.e.
524 the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called.
525 This is only done on debug builds.
527 * API/JSObjectRef.cpp:
528 (JSObjectMakeFunction):
531 (JSObjectMakeRegExp):
532 (JSObjectCallAsFunction):
533 (JSObjectCallAsConstructor):
534 * dfg/DFGOperations.cpp:
535 * inspector/InjectedScriptManager.cpp:
536 (Inspector::InjectedScriptManager::createInjectedScript):
537 * inspector/JSJavaScriptCallFrame.cpp:
538 (Inspector::JSJavaScriptCallFrame::scopeChain const):
539 * interpreter/Interpreter.cpp:
540 (JSC::Interpreter::executeProgram):
542 (functionDollarAgentReceiveBroadcast):
543 * runtime/ArgList.cpp:
544 (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
545 (JSC::MarkedArgumentBuffer::expandCapacity):
546 (JSC::MarkedArgumentBuffer::slowAppend):
548 (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
549 (JSC::MarkedArgumentBuffer::appendWithAction):
550 (JSC::MarkedArgumentBuffer::append):
551 (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow):
552 (JSC::MarkedArgumentBuffer::hasOverflowed):
553 (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck):
554 (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck):
555 * runtime/ArrayPrototype.cpp:
556 * runtime/CommonSlowPaths.cpp:
557 (JSC::SLOW_PATH_DECL):
558 * runtime/GetterSetter.cpp:
560 * runtime/IteratorOperations.cpp:
562 (JSC::iteratorClose):
563 * runtime/JSBoundFunction.cpp:
564 (JSC::boundThisNoArgsFunctionCall):
565 (JSC::boundFunctionCall):
566 (JSC::boundThisNoArgsFunctionConstruct):
567 (JSC::boundFunctionConstruct):
568 * runtime/JSGenericTypedArrayViewConstructorInlines.h:
569 (JSC::constructGenericTypedArrayViewFromIterator):
570 * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
571 (JSC::genericTypedArrayViewProtoFuncSlice):
572 (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
573 * runtime/JSGlobalObject.cpp:
574 (JSC::JSGlobalObject::haveABadTime):
575 * runtime/JSInternalPromise.cpp:
576 (JSC::JSInternalPromise::then):
578 (JSC::JSJobMicrotask::run):
579 * runtime/JSMapIterator.cpp:
580 (JSC::JSMapIterator::createPair):
581 * runtime/JSModuleLoader.cpp:
582 (JSC::JSModuleLoader::provideFetch):
583 (JSC::JSModuleLoader::loadAndEvaluateModule):
584 (JSC::JSModuleLoader::loadModule):
585 (JSC::JSModuleLoader::linkAndEvaluateModule):
586 (JSC::JSModuleLoader::requestImportModule):
587 * runtime/JSONObject.cpp:
588 (JSC::Stringifier::toJSONImpl):
589 (JSC::Stringifier::appendStringifiedValue):
590 (JSC::Walker::callReviver):
591 * runtime/JSObject.cpp:
592 (JSC::ordinarySetSlow):
593 (JSC::callToPrimitiveFunction):
594 (JSC::JSObject::hasInstance):
595 * runtime/JSPromise.cpp:
596 (JSC::JSPromise::initialize):
597 (JSC::JSPromise::resolve):
598 * runtime/JSPromiseDeferred.cpp:
599 (JSC::newPromiseCapability):
601 * runtime/JSSetIterator.cpp:
602 (JSC::JSSetIterator::createPair):
603 * runtime/LiteralParser.cpp:
604 (JSC::LiteralParser<CharType>::parse):
605 * runtime/MapConstructor.cpp:
607 * runtime/ObjectConstructor.cpp:
608 (JSC::defineProperties):
609 * runtime/ProxyObject.cpp:
610 (JSC::performProxyGet):
611 (JSC::ProxyObject::performInternalMethodGetOwnProperty):
612 (JSC::ProxyObject::performHasProperty):
613 (JSC::ProxyObject::performPut):
614 (JSC::performProxyCall):
615 (JSC::performProxyConstruct):
616 (JSC::ProxyObject::performDelete):
617 (JSC::ProxyObject::performPreventExtensions):
618 (JSC::ProxyObject::performIsExtensible):
619 (JSC::ProxyObject::performDefineOwnProperty):
620 (JSC::ProxyObject::performGetOwnPropertyNames):
621 (JSC::ProxyObject::performSetPrototype):
622 (JSC::ProxyObject::performGetPrototype):
623 * runtime/ReflectObject.cpp:
624 (JSC::reflectObjectConstruct):
625 * runtime/SetConstructor.cpp:
627 * runtime/StringPrototype.cpp:
628 (JSC::replaceUsingRegExpSearch):
629 (JSC::replaceUsingStringSearch):
630 * runtime/WeakMapConstructor.cpp:
631 (JSC::constructWeakMap):
632 * runtime/WeakSetConstructor.cpp:
633 (JSC::constructWeakSet):
634 * wasm/js/WasmToJS.cpp:
635 (JSC::Wasm::wasmToJS):
637 2017-11-01 Michael Saboff <msaboff@apple.com>
639 Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
640 https://bugs.webkit.org/show_bug.cgi?id=179140
642 Reviewed by Saam Barati.
644 Added overflow checks to computation of arg count plus this.
646 * dfg/DFGSpeculativeJIT32_64.cpp:
647 (JSC::DFG::SpeculativeJIT::compile):
648 * dfg/DFGSpeculativeJIT64.cpp:
649 (JSC::DFG::SpeculativeJIT::compile):
650 * ftl/FTLLowerDFGToB3.cpp:
651 (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
653 2017-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
655 Unreviewed, use weakPointer instead of FTLOutput::weakPointer
656 https://bugs.webkit.org/show_bug.cgi?id=178934
658 * ftl/FTLLowerDFGToB3.cpp:
659 (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
661 2017-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
663 [JSC] Introduce @toObject
664 https://bugs.webkit.org/show_bug.cgi?id=178726
666 Reviewed by Saam Barati.
668 This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node.
669 Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject
670 is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls
671 ObjectConstructor in LLInt and Baseline.
673 We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to
674 offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation
676 if (this === @undefined || this === null)
677 @throwTypeError("error message");
678 var object = @Object(this);
682 var object = @toObject(this, "error message");
684 And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined,
685 ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world.
686 In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect.
688 It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one.
690 * builtins/ArrayConstructor.js:
692 * builtins/ArrayPrototype.js:
708 (globalPrivate.concatSlowPath):
710 * builtins/DatePrototype.js:
711 (toLocaleString.toDateTimeOptionsAnyAll):
713 (toLocaleDateString.toDateTimeOptionsDateDate):
714 (toLocaleDateString):
715 (toLocaleTimeString.toDateTimeOptionsTimeTime):
716 (toLocaleTimeString):
717 * builtins/GlobalOperations.js:
718 (globalPrivate.copyDataProperties):
719 (globalPrivate.copyDataPropertiesNoExclusions):
720 * builtins/ObjectConstructor.js:
722 * builtins/StringConstructor.js:
724 * builtins/TypedArrayConstructor.js:
726 * builtins/TypedArrayPrototype.js:
729 * bytecode/BytecodeDumper.cpp:
730 (JSC::BytecodeDumper<Block>::dumpBytecode):
731 * bytecode/BytecodeIntrinsicRegistry.h:
732 * bytecode/BytecodeList.json:
733 * bytecode/BytecodeUseDef.h:
734 (JSC::computeUsesForBytecodeOffset):
735 (JSC::computeDefsForBytecodeOffset):
736 * bytecode/CodeBlock.cpp:
737 (JSC::CodeBlock::finishCreation):
738 * bytecompiler/BytecodeGenerator.cpp:
739 (JSC::BytecodeGenerator::emitToObject):
740 * bytecompiler/BytecodeGenerator.h:
741 * bytecompiler/NodesCodegen.cpp:
742 (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject):
743 * dfg/DFGAbstractInterpreterInlines.h:
744 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
745 * dfg/DFGByteCodeParser.cpp:
746 (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
747 (JSC::DFG::ByteCodeParser::parseBlock):
748 * dfg/DFGCapabilities.cpp:
749 (JSC::DFG::capabilityLevel):
750 * dfg/DFGClobberize.h:
751 (JSC::DFG::clobberize):
754 * dfg/DFGFixupPhase.cpp:
755 (JSC::DFG::FixupPhase::fixupNode):
756 (JSC::DFG::FixupPhase::fixupToObject):
757 (JSC::DFG::FixupPhase::fixupCallObjectConstructor):
759 (JSC::DFG::Node::convertToCallObjectConstructor):
760 (JSC::DFG::Node::convertToNewStringObject):
761 (JSC::DFG::Node::convertToNewObject):
762 (JSC::DFG::Node::hasIdentifier):
763 (JSC::DFG::Node::hasHeapPrediction):
764 (JSC::DFG::Node::hasCellOperand):
766 * dfg/DFGOperations.cpp:
767 * dfg/DFGOperations.h:
768 * dfg/DFGPredictionPropagationPhase.cpp:
769 * dfg/DFGSafeToExecute.h:
770 (JSC::DFG::safeToExecute):
771 * dfg/DFGSpeculativeJIT.cpp:
772 (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor):
773 (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
774 * dfg/DFGSpeculativeJIT.h:
775 (JSC::DFG::SpeculativeJIT::callOperation):
776 * dfg/DFGSpeculativeJIT32_64.cpp:
777 (JSC::DFG::SpeculativeJIT::compile):
778 * dfg/DFGSpeculativeJIT64.cpp:
779 (JSC::DFG::SpeculativeJIT::compile):
780 * ftl/FTLCapabilities.cpp:
781 (JSC::FTL::canCompile):
782 * ftl/FTLLowerDFGToB3.cpp:
783 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
784 (JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor):
785 (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
787 (JSC::JIT::privateCompileMainPass):
788 (JSC::JIT::privateCompileSlowCases):
790 * jit/JITOpcodes.cpp:
791 (JSC::JIT::emit_op_to_object):
792 (JSC::JIT::emitSlow_op_to_object):
793 * jit/JITOpcodes32_64.cpp:
794 (JSC::JIT::emit_op_to_object):
795 (JSC::JIT::emitSlow_op_to_object):
796 * jit/JITOperations.cpp:
797 * jit/JITOperations.h:
798 * llint/LowLevelInterpreter32_64.asm:
799 * llint/LowLevelInterpreter64.asm:
800 * runtime/CommonSlowPaths.cpp:
801 (JSC::SLOW_PATH_DECL):
802 * runtime/CommonSlowPaths.h:
804 2017-11-01 Fujii Hironori <Hironori.Fujii@sony.com>
806 Use LazyNeverDestroyed instead of DEFINE_GLOBAL
807 https://bugs.webkit.org/show_bug.cgi?id=174979
809 Reviewed by Yusuke Suzuki.
811 * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC.
813 2017-10-27 Yusuke Suzuki <utatane.tea@gmail.com>
815 [DFG][FTL] Introduce StringSlice
816 https://bugs.webkit.org/show_bug.cgi?id=178934
818 Reviewed by Saam Barati.
820 String.prototype.slice is one of the most frequently called function in ARES-6/Babylon.
821 This patch introduces StringSlice DFG node to optimize it in DFG and FTL.
823 This patch's StringSlice node optimizes the following things.
825 1. Empty string generation is accelerated. It is fully executed inline.
826 2. One char string generation is accelerated. `< 0x100` character is supported right now.
827 It is the same to charAt acceleration.
828 3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized
831 We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL.
832 And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change
833 in subsequent changes.
835 This patch improves ARES-6/Babylon performance by 3% in steady state.
838 Running... Babylon ( 1 to go)
839 firstIteration: 50.05 +- 13.68 ms
840 averageWorstCase: 16.80 +- 1.27 ms
841 steadyState: 7.53 +- 0.22 ms
844 Running... Babylon ( 1 to go)
845 firstIteration: 50.91 +- 13.41 ms
846 averageWorstCase: 16.12 +- 0.99 ms
847 steadyState: 7.30 +- 0.29 ms
849 * dfg/DFGAbstractInterpreterInlines.h:
850 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
851 * dfg/DFGBackwardsPropagationPhase.cpp:
852 (JSC::DFG::BackwardsPropagationPhase::propagate):
853 * dfg/DFGByteCodeParser.cpp:
854 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
855 * dfg/DFGClobberize.h:
856 (JSC::DFG::clobberize):
859 * dfg/DFGFixupPhase.cpp:
860 (JSC::DFG::FixupPhase::fixupNode):
862 * dfg/DFGOperations.cpp:
863 * dfg/DFGOperations.h:
864 * dfg/DFGPredictionPropagationPhase.cpp:
865 * dfg/DFGSafeToExecute.h:
866 (JSC::DFG::safeToExecute):
867 * dfg/DFGSpeculativeJIT.cpp:
868 (JSC::DFG::SpeculativeJIT::compileStringSlice):
869 (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
870 (JSC::DFG::SpeculativeJIT::compileArraySlice):
871 (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
872 * dfg/DFGSpeculativeJIT.h:
873 (JSC::DFG::SpeculativeJIT::callOperation):
874 * dfg/DFGSpeculativeJIT32_64.cpp:
875 (JSC::DFG::SpeculativeJIT::compile):
876 * dfg/DFGSpeculativeJIT64.cpp:
877 (JSC::DFG::SpeculativeJIT::compile):
878 * ftl/FTLCapabilities.cpp:
879 (JSC::FTL::canCompile):
880 * ftl/FTLLowerDFGToB3.cpp:
881 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
882 (JSC::FTL::DFG::LowerDFGToB3::populateSliceRange):
883 (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
884 (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
885 * jit/JITOperations.h:
886 * runtime/Intrinsic.cpp:
887 (JSC::intrinsicName):
888 * runtime/Intrinsic.h:
889 * runtime/StringPrototype.cpp:
890 (JSC::StringPrototype::finishCreation):
892 2017-10-31 JF Bastien <jfbastien@apple.com>
894 WebAssembly: Wasm::IndexOrName has a raw pointer to Name
895 https://bugs.webkit.org/show_bug.cgi?id=176644
897 Reviewed by Michael Saboff.
899 IndexOrName now keeps a RefPtr to its original NameSection, which
900 holds the Name (or references nullptr if Index). Holding onto the
901 entire section seems like the better thing to do, since backtraces
902 probably contain multiple names from the same Module.
904 * JavaScriptCore.xcodeproj/project.pbxproj:
905 * interpreter/Interpreter.cpp:
906 (JSC::GetStackTraceFunctor::operator() const):
907 * interpreter/StackVisitor.h: Frame is no longer POD because of the
909 * runtime/StackFrame.cpp:
910 (JSC::StackFrame::StackFrame):
911 * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
912 (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
913 (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
914 * wasm/WasmBBQPlanInlines.h:
915 (JSC::Wasm::BBQPlan::initializeCallees):
916 * wasm/WasmCallee.cpp:
917 (JSC::Wasm::Callee::Callee):
919 (JSC::Wasm::Callee::create):
920 * wasm/WasmFormat.h: Move NameSection to its own header.
921 (JSC::Wasm::isValidNameType):
922 (JSC::Wasm::NameSection::get): Deleted.
923 * wasm/WasmIndexOrName.cpp:
924 (JSC::Wasm::IndexOrName::IndexOrName):
925 (JSC::Wasm::makeString):
926 * wasm/WasmIndexOrName.h:
927 (JSC::Wasm::IndexOrName::IndexOrName):
928 (JSC::Wasm::IndexOrName::isEmpty const):
929 (JSC::Wasm::IndexOrName::isIndex const):
930 * wasm/WasmModuleInformation.cpp:
931 (JSC::Wasm::ModuleInformation::ModuleInformation):
932 * wasm/WasmModuleInformation.h:
933 (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
934 * wasm/WasmNameSection.h:
935 (JSC::Wasm::NameSection::get):
936 (JSC::Wasm::NameSection::create): Deleted.
937 * wasm/WasmNameSectionParser.cpp:
938 (JSC::Wasm::NameSectionParser::parse):
939 * wasm/WasmNameSectionParser.h:
940 * wasm/WasmOMGPlan.cpp:
941 (JSC::Wasm::OMGPlan::work):
943 2017-10-31 Tim Horton <timothy_horton@apple.com>
945 Clean up some drag and drop feature flags
946 https://bugs.webkit.org/show_bug.cgi?id=179082
948 Reviewed by Simon Fraser.
950 * Configurations/FeatureDefines.xcconfig:
952 2017-10-31 Commit Queue <commit-queue@webkit.org>
954 Unreviewed, rolling out r224243, r224246, and r224248.
955 https://bugs.webkit.org/show_bug.cgi?id=179083
957 The patch and fix broke the Windows build. (Requested by
958 mlewis13 on #webkit).
962 "StructureStubInfo should have GPRReg members not int8_ts"
963 https://bugs.webkit.org/show_bug.cgi?id=179071
964 https://trac.webkit.org/changeset/224243
966 "Make all register enums be backed by uint8_t."
967 https://bugs.webkit.org/show_bug.cgi?id=179074
968 https://trac.webkit.org/changeset/224246
970 "Unreviewed, windows build fix."
971 https://trac.webkit.org/changeset/224248
973 2017-10-31 Tim Horton <timothy_horton@apple.com>
975 Fix up some content filtering feature flags
976 https://bugs.webkit.org/show_bug.cgi?id=179079
978 Reviewed by Simon Fraser.
980 * Configurations/FeatureDefines.xcconfig:
982 2017-10-31 Keith Miller <keith_miller@apple.com>
984 Unreviewed, windows build fix.
986 * assembler/X86Assembler.h:
987 (JSC::X86Assembler::numberOfRegisters):
988 (JSC::X86Assembler::numberOfSPRegisters):
989 (JSC::X86Assembler::numberOfFPRegisters):
991 2017-10-31 Keith Miller <keith_miller@apple.com>
993 Make all register enums be backed by uint8_t.
994 https://bugs.webkit.org/show_bug.cgi?id=179074
996 Reviewed by Mark Lam.
998 * assembler/ARM64Assembler.h:
999 * assembler/ARMAssembler.h:
1000 * assembler/ARMv7Assembler.h:
1001 * assembler/MIPSAssembler.h:
1002 * assembler/MacroAssembler.h:
1003 * assembler/X86Assembler.h:
1005 2017-10-31 Keith Miller <keith_miller@apple.com>
1007 StructureStubInfo should have GPRReg members not int8_ts
1008 https://bugs.webkit.org/show_bug.cgi?id=179071
1010 Reviewed by Michael Saboff.
1012 This patch makes the various RegisterID enums be backed by
1013 uint8_t. This means that we can remove the old int8_t members in
1014 StructureStubInfo and replace them with the correct enum types.
1016 Also, this fixes an indentation issue in ARMv7Assembler.h.
1018 * assembler/ARM64Assembler.h:
1019 * assembler/ARMAssembler.h:
1020 * assembler/ARMv7Assembler.h:
1021 (JSC::ARMRegisters::asSingle):
1022 (JSC::ARMRegisters::asDouble):
1023 * assembler/MIPSAssembler.h:
1024 * assembler/X86Assembler.h:
1025 * bytecode/InlineAccess.cpp:
1026 (JSC::InlineAccess::generateSelfPropertyAccess):
1027 (JSC::getScratchRegister):
1028 * bytecode/PolymorphicAccess.cpp:
1029 (JSC::PolymorphicAccess::regenerate):
1030 * bytecode/StructureStubInfo.h:
1031 (JSC::StructureStubInfo::valueRegs const):
1032 * dfg/DFGSpeculativeJIT.cpp:
1033 (JSC::DFG::SpeculativeJIT::compileIn):
1034 * ftl/FTLLowerDFGToB3.cpp:
1035 (JSC::FTL::DFG::LowerDFGToB3::compileIn):
1036 * jit/JITInlineCacheGenerator.cpp:
1037 (JSC::JITByIdGenerator::JITByIdGenerator):
1038 (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
1040 2017-10-31 Devin Rousso <webkit@devinrousso.com>
1042 Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
1043 https://bugs.webkit.org/show_bug.cgi?id=179048
1045 Reviewed by Mark Lam.
1047 * inspector/ScriptCallStackFactory.h:
1048 * inspector/ScriptCallStackFactory.cpp:
1049 (createScriptCallStack):
1050 (createScriptCallStackForConsole):
1051 (createScriptCallStackFromException):
1053 * inspector/ConsoleMessage.cpp:
1054 (Inspector::ConsoleMessage::autogenerateMetadata):
1055 * inspector/JSGlobalObjectInspectorController.cpp:
1056 (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1057 * inspector/agents/InspectorConsoleAgent.cpp:
1058 (Inspector::InspectorConsoleAgent::count):
1059 * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
1060 (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
1062 2017-10-31 Carlos Garcia Campos <cgarcia@igalia.com>
1064 Unreviewed. Fix GTK+ make distcheck.
1066 Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.
1070 2017-10-30 Saam Barati <sbarati@apple.com>
1072 We need a storeStoreFence before storing to the instruction stream's live variable catch data
1073 https://bugs.webkit.org/show_bug.cgi?id=178649
1075 Reviewed by Keith Miller.
1077 * bytecode/CodeBlock.cpp:
1078 (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
1080 2017-10-30 Michael Catanzaro <mcatanzaro@igalia.com>
1082 [WPE] Fix build warnings
1083 https://bugs.webkit.org/show_bug.cgi?id=178899
1085 Reviewed by Carlos Alberto Lopez Perez.
1087 * PlatformWPE.cmake:
1089 2017-10-30 Zan Dobersek <zdobersek@igalia.com>
1091 [ARMv7] Fix initial start register support in YarrJIT
1092 https://bugs.webkit.org/show_bug.cgi?id=178641
1094 Reviewed by Saam Barati.
1096 * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
1097 YarrGenerator class. r6 should be avoided since it's already used inside
1098 MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
1099 can be used as the frame pointer register when targetting ARM Thumb2.
1101 2017-10-30 Zan Dobersek <zdobersek@igalia.com>
1103 [ARM64][Linux] Re-enable Gigacage
1104 https://bugs.webkit.org/show_bug.cgi?id=178130
1106 Reviewed by Michael Catanzaro.
1108 Guard the current globaladdr opcode implementation for ARM64 with
1109 OS(DARWIN) as it's only usable for Mach-O.
1111 For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
1112 have to be used. The .loh directive can't be used as it's not supported
1113 in GCC or the ld linker.
1115 On every other OS target, a compilation error is thrown.
1117 * offlineasm/arm64.rb:
1119 2017-10-27 Devin Rousso <webkit@devinrousso.com>
1121 Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
1122 https://bugs.webkit.org/show_bug.cgi?id=178799
1123 <rdar://problem/35175805>
1125 Reviewed by Brian Burg.
1127 * inspector/protocol/Canvas.json:
1128 Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.
1130 2017-10-27 Yusuke Suzuki <utatane.tea@gmail.com>
1132 [JSC] Tweak ES6 generator function to allow inlining
1133 https://bugs.webkit.org/show_bug.cgi?id=178935
1135 Reviewed by Saam Barati.
1137 We optimize builtins' generator helper functions to allow them inlined in the caller side.
1138 This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
1139 them inlined in DFG.
1143 spread-generator.es6 301.2637+-11.1011 ^ 260.5905+-14.2258 ^ definitely 1.1561x faster
1144 generator.es6 269.6030+-13.2435 ^ 148.8840+-6.7614 ^ definitely 1.8108x faster
1146 * builtins/GeneratorPrototype.js:
1147 (globalPrivate.generatorResume):
1152 2017-10-27 Saam Barati <sbarati@apple.com>
1154 Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
1155 https://bugs.webkit.org/show_bug.cgi?id=178949
1157 Reviewed by Keith Miller.
1159 This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
1160 so that we don't need to recompute liveness for the same UnlinkedCodeBlock
1161 more than once. To do this, this patch solidifies the invariant that CodeBlock
1162 linking can't do anything that would change the result of liveness. For example,
1163 it can't introduce new locals. This invariant was met my JSC before, because we
1164 didn't do anything in bytecode linking that would change liveness. However, it is
1165 now a correctness requirement that we don't do anything that would change the
1166 result of running liveness. To support this change, I've refactored BytecodeGraph
1167 to not be tied to a CodeBlockType*. Things that perform liveness will pass in
1168 CodeBlockType* and the instruction stream as needed. This means that we may
1169 compute liveness with one CodeBlock*'s instruction stream, and then perform
1170 queries on that analysis with a different CodeBlock*'s instruction stream.
1172 This seems to be a 2% JSBench progression.
1174 * bytecode/BytecodeGeneratorification.cpp:
1175 (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
1176 (JSC::BytecodeGeneratorification::graph):
1177 (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
1178 (JSC::GeneratorLivenessAnalysis::run):
1179 (JSC::BytecodeGeneratorification::run):
1180 * bytecode/BytecodeGraph.h:
1181 (JSC::BytecodeGraph::BytecodeGraph):
1182 (JSC::BytecodeGraph::codeBlock const): Deleted.
1183 (JSC::BytecodeGraph::instructions): Deleted.
1184 (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
1185 * bytecode/BytecodeLivenessAnalysis.cpp:
1186 (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
1187 (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
1188 (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
1189 (JSC::BytecodeLivenessAnalysis::computeKills):
1190 (JSC::BytecodeLivenessAnalysis::dumpResults):
1191 (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
1192 (JSC::BytecodeLivenessAnalysis::compute): Deleted.
1193 * bytecode/BytecodeLivenessAnalysis.h:
1194 * bytecode/BytecodeLivenessAnalysisInlines.h:
1195 (JSC::BytecodeLivenessPropagation::stepOverInstruction):
1196 (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
1197 (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
1198 (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
1199 (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
1200 * bytecode/BytecodeRewriter.cpp:
1201 (JSC::BytecodeRewriter::applyModification):
1202 (JSC::BytecodeRewriter::execute):
1203 (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
1204 * bytecode/BytecodeRewriter.h:
1205 (JSC::BytecodeRewriter::BytecodeRewriter):
1206 (JSC::BytecodeRewriter::removeBytecode):
1207 (JSC::BytecodeRewriter::graph):
1208 * bytecode/CodeBlock.cpp:
1209 (JSC::CodeBlock::finishCreation):
1210 (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
1211 (JSC::CodeBlock::validate):
1212 (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
1213 * bytecode/CodeBlock.h:
1214 (JSC::CodeBlock::livenessAnalysis):
1215 * bytecode/UnlinkedCodeBlock.cpp:
1216 (JSC::UnlinkedCodeBlock::applyModification):
1217 (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
1218 * bytecode/UnlinkedCodeBlock.h:
1219 (JSC::UnlinkedCodeBlock::livenessAnalysis):
1221 (JSC::DFG::Graph::livenessFor):
1222 (JSC::DFG::Graph::killsFor):
1224 (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
1226 (JSC::JIT::privateCompileMainPass):
1228 2017-10-27 Keith Miller <keith_miller@apple.com>
1230 Add unified source list files and build scripts to Xcode project navigator
1231 https://bugs.webkit.org/show_bug.cgi?id=178959
1233 Reviewed by Andy Estes.
1235 Also, Add some extra source files for so new .cpp/.mm files don't cause the build
1236 to fail right away. We already do this in WebCore.
1238 * JavaScriptCore.xcodeproj/project.pbxproj:
1239 * PlatformMac.cmake:
1240 * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.
1242 2017-10-27 JF Bastien <jfbastien@apple.com>
1244 WebAssembly: update arbitrary limits to what browsers use
1245 https://bugs.webkit.org/show_bug.cgi?id=178946
1246 <rdar://problem/34257412>
1247 <rdar://problem/34501154>
1249 Reviewed by Saam Barati.
1251 https://github.com/WebAssembly/design/issues/1138 discusses the
1252 arbitrary function size limit, which it turns out Chrome and
1253 Firefox didn't enforce. We didn't use it because it was
1254 ridiculously low and actual programs ran into that limit (bummer
1255 for Edge which just shipped it...). Now that we agree on a high
1256 arbitrary program limit, let's update it! While I'm doing this
1257 there are a few other spots that I polished to use Checked or
1258 better check limits overall.
1260 * wasm/WasmB3IRGenerator.cpp:
1261 (JSC::Wasm::B3IRGenerator::addLocal):
1262 * wasm/WasmFormat.cpp:
1263 (JSC::Wasm::Segment::create):
1264 * wasm/WasmFunctionParser.h:
1265 (JSC::Wasm::FunctionParser<Context>::parse):
1266 * wasm/WasmInstance.cpp:
1267 * wasm/WasmLimits.h:
1268 * wasm/WasmModuleParser.cpp:
1269 (JSC::Wasm::ModuleParser::parseGlobal):
1270 (JSC::Wasm::ModuleParser::parseCode):
1271 (JSC::Wasm::ModuleParser::parseData):
1272 * wasm/WasmSignature.h:
1273 (JSC::Wasm::Signature::allocatedSize):
1274 * wasm/WasmTable.cpp:
1275 (JSC::Wasm::Table::Table):
1276 * wasm/js/JSWebAssemblyTable.cpp:
1277 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1278 (JSC::JSWebAssemblyTable::grow):
1280 2017-10-26 Michael Saboff <msaboff@apple.com>
1282 REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
1283 https://bugs.webkit.org/show_bug.cgi?id=178890
1285 Reviewed by Keith Miller.
1287 We need to let a contained subpattern backtrack before declaring that the containing
1288 parenthesis doesn't match. If the subpattern fails to match backtracking, then we
1289 can check to see if we trying to backtrack below the minimum match count.
1291 * yarr/YarrInterpreter.cpp:
1292 (JSC::Yarr::Interpreter::backtrackParentheses):
1294 2017-10-26 Mark Lam <mark.lam@apple.com>
1296 JSRopeString::RopeBuilder::append() should check for overflows.
1297 https://bugs.webkit.org/show_bug.cgi?id=178385
1298 <rdar://problem/35027468>
1300 Reviewed by Saam Barati.
1302 1. Made RopeString check for overflow like the Checked class does.
1303 2. Added a missing overflow check in objectProtoFuncToString().
1305 * runtime/JSString.cpp:
1306 (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
1307 (JSC::JSRopeString::RopeBuilder::expand): Deleted.
1308 * runtime/JSString.h:
1309 * runtime/ObjectPrototype.cpp:
1310 (JSC::objectProtoFuncToString):
1311 * runtime/Operations.h:
1312 (JSC::jsStringFromRegisterArray):
1313 (JSC::jsStringFromArguments):
1315 2017-10-26 JF Bastien <jfbastien@apple.com>
1317 WebAssembly: no VM / JS version of our implementation
1318 https://bugs.webkit.org/show_bug.cgi?id=177472
1320 Reviewed by Michael Saboff.
1322 This patch removes all appearances of "JS" and "VM" in the wasm
1323 directory. These now only appear in the wasm/js directory, which
1324 is only used in a JS embedding of wasm. It should therefore now be
1325 possible to create non-JS embeddings of wasm through JSC, though
1326 it'll still require:
1328 - Mild codegen for wasm<->embedder calls;
1329 - A strategy for trap handling (no need for full unwind! Could kill).
1330 - Creation of the Wasm::* objects.
1331 - Calling convention handling to call the embedder.
1332 - Handling of multiple embedders (see #177475, this is optional).
1334 Most of the patch consists in renaming JSWebAssemblyInstance to
1335 Instance, and removing temporary copies which I'd added to make
1336 this specific patch very simple.
1338 * interpreter/CallFrame.cpp:
1339 (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
1340 which needs to know about who "owns" the Wasm::Instance. In a JS
1341 embedding it's the JSWebAssemblyInstance.
1342 * wasm/WasmB3IRGenerator.cpp:
1343 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1344 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1345 (JSC::Wasm::B3IRGenerator::addGrowMemory):
1346 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1347 (JSC::Wasm::B3IRGenerator::getGlobal):
1348 (JSC::Wasm::B3IRGenerator::setGlobal):
1349 (JSC::Wasm::B3IRGenerator::addCall):
1350 (JSC::Wasm::B3IRGenerator::addCallIndirect):
1351 * wasm/WasmBinding.cpp:
1352 (JSC::Wasm::wasmToWasm):
1353 * wasm/WasmContext.cpp:
1354 (JSC::Wasm::Context::load const):
1355 (JSC::Wasm::Context::store):
1356 * wasm/WasmContext.h:
1357 * wasm/WasmEmbedder.h:
1358 * wasm/WasmInstance.cpp:
1359 (JSC::Wasm::Instance::Instance):
1360 (JSC::Wasm::Instance::create):
1361 (JSC::Wasm::Instance::extraMemoryAllocated const):
1362 * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
1363 "tail" import information from JSWebAssemblyInstance over to here.
1364 (JSC::Wasm::Instance::finalizeCreation):
1365 (JSC::Wasm::Instance::owner const):
1366 (JSC::Wasm::Instance::offsetOfOwner):
1367 (JSC::Wasm::Instance::context const):
1368 (JSC::Wasm::Instance::setMemory):
1369 (JSC::Wasm::Instance::setTable):
1370 (JSC::Wasm::Instance::offsetOfMemory):
1371 (JSC::Wasm::Instance::offsetOfGlobals):
1372 (JSC::Wasm::Instance::offsetOfTable):
1373 (JSC::Wasm::Instance::offsetOfTail):
1374 (JSC::Wasm::Instance::numImportFunctions const):
1375 (JSC::Wasm::Instance::importFunctionInfo):
1376 (JSC::Wasm::Instance::offsetOfTargetInstance):
1377 (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
1378 (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
1379 (JSC::Wasm::Instance::offsetOfImportFunction):
1380 (JSC::Wasm::Instance::importFunction):
1381 (JSC::Wasm::Instance::allocationSize):
1382 (JSC::Wasm::Instance::create): Deleted.
1383 * wasm/WasmOMGPlan.cpp:
1384 (JSC::Wasm::OMGPlan::runForIndex):
1385 * wasm/WasmOMGPlan.h:
1386 * wasm/WasmTable.cpp:
1387 (JSC::Wasm::Table::Table):
1388 (JSC::Wasm::Table::setFunction):
1390 * wasm/WasmThunks.cpp:
1391 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1392 (JSC::Wasm::triggerOMGTierUpThunkGenerator):
1393 * wasm/js/JSToWasm.cpp:
1394 (JSC::Wasm::createJSToWasmWrapper):
1395 * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
1396 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
1397 decides what the import function is. Here we must properly
1398 placement-new it to what we've elected (and initialize it later).
1399 (JSC::JSWebAssemblyInstance::visitChildren):
1400 (JSC::JSWebAssemblyInstance::finalizeCreation):
1401 (JSC::JSWebAssemblyInstance::create):
1402 * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
1403 (JSC::JSWebAssemblyInstance::instance):
1404 (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
1405 (JSC::JSWebAssemblyInstance::setMemory):
1406 (JSC::JSWebAssemblyInstance::table):
1407 (JSC::JSWebAssemblyInstance::setTable):
1408 (JSC::JSWebAssemblyInstance::offsetOfInstance):
1409 (JSC::JSWebAssemblyInstance::offsetOfCallee):
1410 (JSC::JSWebAssemblyInstance::context const): Deleted.
1411 (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
1413 (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
1414 (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
1415 (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
1416 (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
1417 (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
1418 (JSC::JSWebAssemblyInstance::importFunction): Deleted.
1419 (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
1420 (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
1421 (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
1422 (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
1423 (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
1424 (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
1425 (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
1426 (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
1427 (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
1428 (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
1429 (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
1430 (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
1431 (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
1432 (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
1433 * wasm/js/JSWebAssemblyTable.cpp:
1434 (JSC::JSWebAssemblyTable::setFunction):
1435 * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
1436 (JSC::Wasm::materializeImportJSCell):
1437 (JSC::Wasm::handleBadI64Use):
1438 (JSC::Wasm::wasmToJS):
1439 (JSC::Wasm::wasmToJSException):
1440 * wasm/js/WasmToJS.h:
1441 * wasm/js/WebAssemblyFunction.cpp:
1442 (JSC::callWebAssemblyFunction):
1443 * wasm/js/WebAssemblyInstanceConstructor.cpp:
1444 (JSC::constructJSWebAssemblyInstance):
1445 * wasm/js/WebAssemblyModuleRecord.cpp:
1446 (JSC::WebAssemblyModuleRecord::link):
1447 (JSC::WebAssemblyModuleRecord::evaluate):
1448 * wasm/js/WebAssemblyPrototype.cpp:
1450 * wasm/js/WebAssemblyWrapperFunction.cpp:
1451 (JSC::WebAssemblyWrapperFunction::create):
1453 2017-10-25 Devin Rousso <webkit@devinrousso.com>
1455 Web Inspector: provide a way to enable/disable event listeners
1456 https://bugs.webkit.org/show_bug.cgi?id=177451
1457 <rdar://problem/34994925>
1459 Reviewed by Joseph Pecoraro.
1461 * inspector/protocol/DOM.json:
1462 Add `setEventListenerDisabled` command that enables/disables a specific event listener
1463 during event dispatch. When a disabled event listener is fired, the listener's callback will
1466 2017-10-25 Commit Queue <commit-queue@webkit.org>
1468 Unreviewed, rolling out r223691 and r223729.
1469 https://bugs.webkit.org/show_bug.cgi?id=178834
1471 Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
1472 by rniwa on #webkit).
1474 Reverted changesets:
1476 "Turn recursive tail calls into loops"
1477 https://bugs.webkit.org/show_bug.cgi?id=176601
1478 https://trac.webkit.org/changeset/223691
1480 "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
1481 comparison is always false due to limited range of data type
1483 https://bugs.webkit.org/show_bug.cgi?id=178543
1484 https://trac.webkit.org/changeset/223729
1486 2017-10-25 Michael Saboff <msaboff@apple.com>
1488 REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
1489 https://bugs.webkit.org/show_bug.cgi?id=178825
1491 Reviewed by Mark Lam.
1493 Enable ARC for ARM64_32. This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
1495 * Configurations/ToolExecutable.xcconfig:
1497 2017-10-25 Keith Miller <keith_miller@apple.com>
1499 Fix implicit cast of enum, which seems to break the windows build of unified sources.
1500 https://bugs.webkit.org/show_bug.cgi?id=178822
1502 Reviewed by Saam Barati.
1504 * bytecode/DFGExitProfile.h:
1505 (JSC::DFG::FrequentExitSite::hash const):
1507 2017-10-24 Michael Saboff <msaboff@apple.com>
1509 Allow OjbC Weak References when building TestAPI
1510 https://bugs.webkit.org/show_bug.cgi?id=178748
1512 Reviewed by Dan Bernstein.
1514 Set TestAPI build flag Weak References in Manual Retain Release to true.
1516 * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
1517 * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
1519 2017-10-24 Eric Carlson <eric.carlson@apple.com>
1521 Web Inspector: Enable WebKit logging configuration and display
1522 https://bugs.webkit.org/show_bug.cgi?id=177027
1523 <rdar://problem/33964767>
1525 Reviewed by Joseph Pecoraro.
1527 * inspector/ConsoleMessage.cpp:
1528 (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage ->
1529 Inspector::Protocol::Console::ChannelSource.
1530 * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
1531 (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
1532 specific to a JSContext yet, so return an empty channel array.
1533 (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
1534 * inspector/agents/JSGlobalObjectConsoleAgent.h:
1536 * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
1537 and setLoggingChannelLevel.
1539 * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
1540 * inspector/scripts/tests/generic/expected/enum-values.json-result:
1541 * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1542 * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1543 * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1544 * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1546 * runtime/ConsoleTypes.h: Add Media and WebRTC.
1548 2017-10-24 Michael Saboff <msaboff@apple.com>
1550 Allow OjbC Weak References when building TestAPI
1551 https://bugs.webkit.org/show_bug.cgi?id=178748
1553 Reviewed by Saam Barati.
1555 Set TestAPI build flag Weak References in Manual Retain Release to true.
1557 * JavaScriptCore.xcodeproj/project.pbxproj:
1559 2017-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
1561 [FTL] Support NewStringObject
1562 https://bugs.webkit.org/show_bug.cgi?id=178737
1564 Reviewed by Saam Barati.
1566 FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
1567 After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
1569 * ftl/FTLAbstractHeapRepository.h:
1570 * ftl/FTLCapabilities.cpp:
1571 (JSC::FTL::canCompile):
1572 * ftl/FTLLowerDFGToB3.cpp:
1573 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1574 (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
1576 2017-10-24 Guillaume Emont <guijemont@igalia.com>
1578 [mips] fix offsets of branches that have to go over a jump
1579 https://bugs.webkit.org/show_bug.cgi?id=153464
1581 The jump() function creates 8 instructions, but the offsets of branches
1582 meant to go over them only account for 6. In most cases, this is not an
1583 issue as the last two instructions of jump() would be nops, but in the
1584 rarer case where the jump destination is in a different 256 MB segment,
1585 MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
1586 the last 4 instructions would be a 2 instruction load (lui/ori) into
1587 $t9, a "j $t9" and then a nop. The wrong offset will mean that the
1588 previous branches meant to go over the whole jump will branch to the
1589 "j $t9" instruction, which would jump to whatever is currently in $t9
1590 (since lui/ori would not be executed).
1592 Reviewed by Michael Catanzaro.
1594 * assembler/MacroAssemblerMIPS.h:
1595 (JSC::MacroAssemblerMIPS::branchAdd32):
1596 (JSC::MacroAssemblerMIPS::branchMul32):
1597 (JSC::MacroAssemblerMIPS::branchSub32):
1598 Fix the offsets of branches meant to go over code generated by jump().
1600 2017-10-24 JF Bastien <jfbastien@apple.com>
1602 WebAssembly: NFC renames of things that aren't JS-specific
1603 https://bugs.webkit.org/show_bug.cgi?id=178738
1605 Reviewed by Saam Barati.
1607 * wasm/WasmB3IRGenerator.cpp:
1608 (JSC::Wasm::parseAndCompile):
1609 * wasm/WasmB3IRGenerator.h:
1610 * wasm/WasmBBQPlan.cpp:
1611 (JSC::Wasm::BBQPlan::complete):
1612 * wasm/WasmCodeBlock.cpp:
1613 (JSC::Wasm::CodeBlock::CodeBlock):
1614 * wasm/WasmCodeBlock.h:
1615 (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
1616 (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
1617 * wasm/WasmFormat.h:
1618 * wasm/js/JSToWasm.cpp:
1619 (JSC::Wasm::createJSToWasmWrapper):
1620 * wasm/js/WebAssemblyModuleRecord.cpp:
1621 (JSC::WebAssemblyModuleRecord::link):
1622 (JSC::WebAssemblyModuleRecord::evaluate):
1624 2017-10-24 Stephan Szabo <stephan.szabo@sony.com>
1626 [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
1627 https://bugs.webkit.org/show_bug.cgi?id=177279
1629 Reviewed by Yusuke Suzuki.
1631 * shell/PlatformJSCOnly.cmake: Added.
1633 2017-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
1635 [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
1636 https://bugs.webkit.org/show_bug.cgi?id=178308
1638 Reviewed by Mark Lam.
1640 With the change of the spec[1], we now do not need to remember star resolution modules.
1641 We reflect this change to our implementation. Since this change is covered by test262,
1642 this patch improves the score of test262.
1644 We also add logging to ResolveExport to debug it easily.
1646 [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
1648 * runtime/AbstractModuleRecord.cpp:
1649 (JSC::AbstractModuleRecord::ResolveQuery::dump const):
1650 (JSC::AbstractModuleRecord::resolveExportImpl):
1652 2017-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
1654 [JSC] Use emitDumbVirtualCall in 32bit JIT
1655 https://bugs.webkit.org/show_bug.cgi?id=178644
1657 Reviewed by Mark Lam.
1659 This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
1661 * jit/JITCall32_64.cpp:
1662 (JSC::JIT::compileCallEvalSlowCase):
1664 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1666 [JSC] Drop ArityCheckData
1667 https://bugs.webkit.org/show_bug.cgi?id=178648
1669 Reviewed by Mark Lam.
1671 ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
1672 However, use of `thunkToCall` is removed in 64bit environment at r189575.
1674 We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
1675 Since we no longer need to have the above pair, we can remove ArityCheckData too.
1677 * llint/LowLevelInterpreter32_64.asm:
1678 * llint/LowLevelInterpreter64.asm:
1679 * runtime/CommonSlowPaths.cpp:
1680 (JSC::SLOW_PATH_DECL):
1681 (JSC::setupArityCheckData): Deleted.
1682 * runtime/CommonSlowPaths.h:
1687 2017-10-23 Keith Miller <keith_miller@apple.com>
1689 Unreviewed, reland r223866
1691 Didn't break the windows build...
1695 "WebAssembly: topEntryFrame on Wasm::Instance"
1696 https://bugs.webkit.org/show_bug.cgi?id=178690
1697 https://trac.webkit.org/changeset/223866
1700 2017-10-23 Commit Queue <commit-queue@webkit.org>
1702 Unreviewed, rolling out r223866.
1703 https://bugs.webkit.org/show_bug.cgi?id=178699
1705 Probably broke the windows build (Requested by keith_miller on
1710 "WebAssembly: topEntryFrame on Wasm::Instance"
1711 https://bugs.webkit.org/show_bug.cgi?id=178690
1712 https://trac.webkit.org/changeset/223866
1714 2017-10-23 Joseph Pecoraro <pecoraro@apple.com>
1716 Web Inspector: Remove unused Console.setMonitoringXHREnabled
1717 https://bugs.webkit.org/show_bug.cgi?id=178617
1719 Reviewed by Sam Weinig.
1721 * JavaScriptCore.xcodeproj/project.pbxproj:
1723 * inspector/agents/InspectorConsoleAgent.h:
1724 * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1725 * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1726 * inspector/protocol/Console.json:
1727 Removed files and method.
1729 * inspector/JSGlobalObjectInspectorController.cpp:
1730 (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1731 This can use the base ConsoleAgent now.
1733 2017-10-23 JF Bastien <jfbastien@apple.com>
1735 WebAssembly: topEntryFrame on Wasm::Instance
1736 https://bugs.webkit.org/show_bug.cgi?id=178690
1738 Reviewed by Saam Barati.
1740 topEntryFrame is usually on VM, but for a no-VM WebAssembly we
1741 need to hold topEntryFrame elsewhere, and generated code cannot
1742 hard-code where topEntryFrame live. Do this at creation time of
1743 Wasm::Instance, and then generated code will just load from
1744 wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
1745 embedding this is still from VM, so all of the unwinding machinery
1748 * dfg/DFGOSREntry.cpp:
1749 (JSC::DFG::prepareOSREntry):
1750 * dfg/DFGOSRExit.cpp:
1751 (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
1752 (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1753 * ftl/FTLOSRExitCompiler.cpp:
1754 (JSC::FTL::compileStub):
1755 * interpreter/Interpreter.cpp:
1756 (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1757 * jit/AssemblyHelpers.cpp:
1758 (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1759 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1760 * jit/AssemblyHelpers.h:
1761 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1762 The default parameter was never non-defaulted from any of the
1763 callers. The new version calls the impl directly because it
1764 doesn't have VM and doesn't hard-code the address of
1766 * jit/RegisterSet.cpp:
1767 (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
1768 VM because it's not really VM-specific.
1769 * jit/RegisterSet.h:
1771 (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
1773 (JSC::VM::getCTIStub):
1774 * wasm/WasmB3IRGenerator.cpp:
1775 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1776 (JSC::Wasm::B3IRGenerator::addCall):
1777 (JSC::Wasm::B3IRGenerator::addCallIndirect):
1778 * wasm/WasmInstance.cpp:
1779 (JSC::Wasm::Instance::Instance):
1780 * wasm/WasmInstance.h: topEntryFramePointer will eventually live
1781 here for real. Right now it's mirrored in JSWebAssemblyInstance
1782 because that's the acting Context.
1783 (JSC::Wasm::Instance::create):
1784 (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
1785 * wasm/WasmThunks.cpp:
1786 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1787 * wasm/js/JSWebAssemblyInstance.cpp:
1788 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1789 * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
1790 (JSC::JSWebAssemblyInstance::offsetOfCallee):
1791 (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
1792 (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
1793 * wasm/js/WebAssemblyInstanceConstructor.cpp:
1794 (JSC::constructJSWebAssemblyInstance):
1795 * wasm/js/WebAssemblyPrototype.cpp:
1798 2017-10-23 Joseph Pecoraro <pecoraro@apple.com>
1800 Web Inspector: Please support HAR Export for network traffic
1801 https://bugs.webkit.org/show_bug.cgi?id=146692
1802 <rdar://problem/7463672>
1804 Reviewed by Brian Burg.
1806 * inspector/protocol/Network.json:
1807 Add a walltime to each send request.
1809 2017-10-23 Matt Lewis <jlewis3@apple.com>
1811 Unreviewed, rolling out r223820.
1813 This caused a build break on Windows.
1817 "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
1818 https://bugs.webkit.org/show_bug.cgi?id=178617
1819 https://trac.webkit.org/changeset/223820
1821 2017-10-23 Yusuke Suzuki <utatane.tea@gmail.com>
1823 [JSC] Use fastJoin in Array#toString
1824 https://bugs.webkit.org/show_bug.cgi?id=178062
1826 Reviewed by Darin Adler.
1828 Array#toString()'s fast path uses original join operation.
1829 But this should use fastJoin if possible.
1830 This patch adds a fast path using fastJoin in Array#toString.
1831 And we also extend fastJoin to perform fast joining for int32
1836 double-array-to-string 126.6157+-5.8625 ^ 103.7343+-4.4968 ^ definitely 1.2206x faster
1837 int32-array-to-string 64.7792+-2.6524 61.2390+-2.1749 might be 1.0578x faster
1838 contiguous-array-to-string 62.6224+-2.6388 ^ 56.9899+-2.0852 ^ definitely 1.0988x faster
1841 * runtime/ArrayPrototype.cpp:
1843 (JSC::arrayProtoFuncToString):
1844 (JSC::arrayProtoFuncToLocaleString):
1845 * runtime/JSStringJoiner.h:
1846 (JSC::JSStringJoiner::appendWithoutSideEffects):
1847 (JSC::JSStringJoiner::appendInt32):
1848 (JSC::JSStringJoiner::appendDouble):
1850 2017-10-22 Zan Dobersek <zdobersek@igalia.com>
1852 [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
1853 https://bugs.webkit.org/show_bug.cgi?id=178452
1855 Reviewed by Yusuke Suzuki.
1857 * heap/RegisterState.h: Re-enable the custom RegisterState and
1858 ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
1859 cause any crashes nowadays.
1861 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1863 [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
1864 https://bugs.webkit.org/show_bug.cgi?id=178647
1866 Reviewed by Saam Barati.
1868 There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
1869 since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
1870 which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
1871 this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
1874 (JSC::JIT::linkAllSlowCases):
1875 * jit/JITArithmetic.cpp:
1876 (JSC::JIT::emitSlow_op_unsigned):
1877 (JSC::JIT::emit_compareAndJump):
1878 (JSC::JIT::emit_compareAndJumpSlow):
1879 (JSC::JIT::emitSlow_op_inc):
1880 (JSC::JIT::emitSlow_op_dec):
1881 (JSC::JIT::emitSlow_op_mod):
1882 (JSC::JIT::emitSlow_op_negate):
1883 (JSC::JIT::emitSlow_op_bitand):
1884 (JSC::JIT::emitSlow_op_bitor):
1885 (JSC::JIT::emitSlow_op_bitxor):
1886 (JSC::JIT::emitSlow_op_lshift):
1887 (JSC::JIT::emitSlow_op_rshift):
1888 (JSC::JIT::emitSlow_op_urshift):
1889 (JSC::JIT::emitSlow_op_add):
1890 (JSC::JIT::emitSlow_op_div):
1891 (JSC::JIT::emitSlow_op_mul):
1892 (JSC::JIT::emitSlow_op_sub):
1893 * jit/JITArithmetic32_64.cpp:
1894 (JSC::JIT::emit_compareAndJumpSlow):
1895 (JSC::JIT::emitSlow_op_unsigned):
1896 (JSC::JIT::emitSlow_op_inc):
1897 (JSC::JIT::emitSlow_op_dec):
1898 (JSC::JIT::emitSlow_op_mod):
1900 (JSC::JIT::compileCallEvalSlowCase):
1901 (JSC::JIT::compileOpCallSlowCase):
1902 * jit/JITCall32_64.cpp:
1903 (JSC::JIT::compileCallEvalSlowCase):
1904 (JSC::JIT::compileOpCallSlowCase):
1906 (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
1907 * jit/JITOpcodes.cpp:
1908 (JSC::JIT::emitSlow_op_new_object):
1909 (JSC::JIT::emitSlow_op_create_this):
1910 (JSC::JIT::emitSlow_op_check_tdz):
1911 (JSC::JIT::emitSlow_op_to_this):
1912 (JSC::JIT::emitSlow_op_to_primitive):
1913 (JSC::JIT::emitSlow_op_not):
1914 (JSC::JIT::emitSlow_op_eq):
1915 (JSC::JIT::emitSlow_op_neq):
1916 (JSC::JIT::emitSlow_op_stricteq):
1917 (JSC::JIT::emitSlow_op_nstricteq):
1918 (JSC::JIT::emitSlow_op_instanceof):
1919 (JSC::JIT::emitSlow_op_instanceof_custom):
1920 (JSC::JIT::emitSlow_op_to_number):
1921 (JSC::JIT::emitSlow_op_to_string):
1922 (JSC::JIT::emitSlow_op_loop_hint):
1923 (JSC::JIT::emitSlow_op_check_traps):
1924 (JSC::JIT::emitSlow_op_has_indexed_property):
1925 (JSC::JIT::emitSlow_op_get_direct_pname):
1926 (JSC::JIT::emitSlow_op_has_structure_property):
1927 * jit/JITOpcodes32_64.cpp:
1928 (JSC::JIT::emitSlow_op_new_object):
1929 (JSC::JIT::emitSlow_op_instanceof):
1930 (JSC::JIT::emitSlow_op_instanceof_custom):
1931 (JSC::JIT::emitSlow_op_to_primitive):
1932 (JSC::JIT::emitSlow_op_not):
1933 (JSC::JIT::emitSlow_op_stricteq):
1934 (JSC::JIT::emitSlow_op_nstricteq):
1935 (JSC::JIT::emitSlow_op_to_number):
1936 (JSC::JIT::emitSlow_op_to_string):
1937 (JSC::JIT::emitSlow_op_create_this):
1938 (JSC::JIT::emitSlow_op_to_this):
1939 (JSC::JIT::emitSlow_op_check_tdz):
1940 (JSC::JIT::emitSlow_op_has_indexed_property):
1941 (JSC::JIT::emitSlow_op_get_direct_pname):
1942 * jit/JITPropertyAccess.cpp:
1943 (JSC::JIT::emitSlow_op_try_get_by_id):
1944 (JSC::JIT::emitSlow_op_get_by_id):
1945 (JSC::JIT::emitSlow_op_get_by_id_with_this):
1946 (JSC::JIT::emitSlow_op_put_by_id):
1947 (JSC::JIT::emitSlow_op_resolve_scope):
1948 (JSC::JIT::emitSlow_op_get_from_scope):
1949 (JSC::JIT::emitSlow_op_put_to_scope):
1950 * jit/JITPropertyAccess32_64.cpp:
1951 (JSC::JIT::emitSlow_op_try_get_by_id):
1952 (JSC::JIT::emitSlow_op_get_by_id):
1953 (JSC::JIT::emitSlow_op_get_by_id_with_this):
1954 (JSC::JIT::emitSlow_op_put_by_id):
1955 (JSC::JIT::emitSlow_op_resolve_scope):
1956 (JSC::JIT::emitSlow_op_get_from_scope):
1957 (JSC::JIT::emitSlow_op_put_to_scope):
1959 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1961 [JSC] Clean up baseline slow path
1962 https://bugs.webkit.org/show_bug.cgi?id=178646
1964 Reviewed by Saam Barati.
1966 If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
1967 It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
1968 function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
1969 code in baseline JIT.
1972 (JSC::JIT::privateCompileMainPass):
1974 * jit/JITArithmetic.cpp:
1975 (JSC::JIT::emit_op_pow): Deleted.
1976 * jit/JITArithmetic32_64.cpp:
1977 (JSC::JIT::emitSlow_op_mod):
1978 * jit/JITOpcodes.cpp:
1979 (JSC::JIT::emit_op_strcat): Deleted.
1980 (JSC::JIT::emit_op_push_with_scope): Deleted.
1981 (JSC::JIT::emit_op_assert): Deleted.
1982 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1983 (JSC::JIT::emit_op_throw_static_error): Deleted.
1984 (JSC::JIT::emit_op_new_array_with_spread): Deleted.
1985 (JSC::JIT::emit_op_spread): Deleted.
1986 (JSC::JIT::emit_op_get_enumerable_length): Deleted.
1987 (JSC::JIT::emit_op_has_generic_property): Deleted.
1988 (JSC::JIT::emit_op_get_property_enumerator): Deleted.
1989 (JSC::JIT::emit_op_to_index_string): Deleted.
1990 (JSC::JIT::emit_op_create_direct_arguments): Deleted.
1991 (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
1992 (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
1993 (JSC::JIT::emit_op_create_rest): Deleted.
1994 (JSC::JIT::emit_op_unreachable): Deleted.
1995 * jit/JITOpcodes32_64.cpp:
1996 (JSC::JIT::emit_op_strcat): Deleted.
1997 (JSC::JIT::emit_op_push_with_scope): Deleted.
1998 (JSC::JIT::emit_op_assert): Deleted.
1999 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
2000 * jit/JITPropertyAccess.cpp:
2001 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
2002 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
2003 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
2004 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
2005 (JSC::JIT::emit_op_define_data_property): Deleted.
2006 (JSC::JIT::emit_op_define_accessor_property): Deleted.
2007 * jit/JITPropertyAccess32_64.cpp:
2008 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
2009 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
2010 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
2011 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
2013 2017-10-21 Joseph Pecoraro <pecoraro@apple.com>
2015 Web Inspector: Remove unused Console.setMonitoringXHREnabled
2016 https://bugs.webkit.org/show_bug.cgi?id=178617
2018 Reviewed by Sam Weinig.
2020 * JavaScriptCore.xcodeproj/project.pbxproj:
2022 * inspector/agents/InspectorConsoleAgent.h:
2023 * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
2024 * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
2025 * inspector/protocol/Console.json:
2026 Removed files and method.
2028 * inspector/JSGlobalObjectInspectorController.cpp:
2029 (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2030 This can use the base ConsoleAgent now.
2032 2017-10-21 Yusuke Suzuki <utatane.tea@gmail.com>
2034 [JSC] Remove per-host-function CTI stub in 32bit environment
2035 https://bugs.webkit.org/show_bug.cgi?id=178581
2037 Reviewed by Saam Barati.
2039 JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
2040 The only difference is that it embed the address of the host function directly in the generated stub. This means
2041 that we have per-host-function CTI stub only in 32bit environment.
2043 This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
2046 (JSC::JIT::compileCTINativeCall): Deleted.
2048 * jit/JITOpcodes.cpp:
2049 (JSC::JIT::privateCompileCTINativeCall): Deleted.
2050 * jit/JITOpcodes32_64.cpp:
2051 (JSC::JIT::privateCompileCTINativeCall): Deleted.
2052 * jit/JITThunks.cpp:
2053 (JSC::JITThunks::hostFunctionStub):
2055 2017-10-20 Antoine Quint <graouts@apple.com>
2057 [Web Animations] Provide basic timeline and animation interfaces
2058 https://bugs.webkit.org/show_bug.cgi?id=178526
2060 Reviewed by Dean Jackson.
2062 Remove the WEB_ANIMATIONS compile-time flag.
2064 * Configurations/FeatureDefines.xcconfig:
2066 2017-10-20 Commit Queue <commit-queue@webkit.org>
2068 Unreviewed, rolling out r223744, r223750, and r223751.
2069 https://bugs.webkit.org/show_bug.cgi?id=178594
2071 These caused consistent failures in test that existed and were
2072 added in the patches. (Requested by mlewis13 on #webkit).
2074 Reverted changesets:
2076 "[JSC] ScriptFetcher should be notified directly from module
2078 https://bugs.webkit.org/show_bug.cgi?id=178340
2079 https://trac.webkit.org/changeset/223744
2081 "Unreviewed, fix changed line number in test expect files"
2082 https://bugs.webkit.org/show_bug.cgi?id=178340
2083 https://trac.webkit.org/changeset/223750
2085 "Unreviewed, follow up to reflect comments"
2086 https://bugs.webkit.org/show_bug.cgi?id=178340
2087 https://trac.webkit.org/changeset/223751
2089 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2091 Unreviewed, follow up to reflect comments
2092 https://bugs.webkit.org/show_bug.cgi?id=178340
2094 * runtime/JSModuleLoader.cpp:
2095 (JSC::JSModuleLoader::notifyCompleted):
2097 2017-10-20 Saam Barati <sbarati@apple.com>
2099 Optimize accesses to how we get the direct prototype
2100 https://bugs.webkit.org/show_bug.cgi?id=178548
2102 Reviewed by Yusuke Suzuki.
2104 This patch makes JSObject::getPrototypeDirect take VM& as a parameter
2105 so it can use the faster version of the structure accessor function.
2106 The reason for making this change is that JSObjet::getPrototypeDirect
2107 is called on the hot path in property lookup.
2109 * API/JSObjectRef.cpp:
2110 (JSObjectGetPrototype):
2112 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
2113 (WTF::DOMJITGetterBaseJSObject::customGetter):
2114 (functionCreateProxy):
2115 * runtime/ArrayPrototype.cpp:
2116 (JSC::speciesWatchpointIsValid):
2117 * runtime/ErrorInstance.cpp:
2118 (JSC::ErrorInstance::sanitizedToString):
2119 * runtime/JSArray.cpp:
2120 (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
2121 * runtime/JSGlobalObject.cpp:
2122 (JSC::JSGlobalObject::init):
2123 (JSC::lastInPrototypeChain):
2124 (JSC::JSGlobalObject::resetPrototype):
2125 (JSC::JSGlobalObject::finishCreation):
2126 * runtime/JSGlobalObjectInlines.h:
2127 (JSC::JSGlobalObject::objectPrototypeIsSane):
2128 (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
2129 (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2130 * runtime/JSLexicalEnvironment.cpp:
2131 (JSC::JSLexicalEnvironment::getOwnPropertySlot):
2132 * runtime/JSMap.cpp:
2133 (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
2134 * runtime/JSObject.cpp:
2135 (JSC::JSObject::calculatedClassName):
2136 (JSC::JSObject::setPrototypeWithCycleCheck):
2137 (JSC::JSObject::getPrototype):
2138 (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
2139 (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
2140 (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
2141 (JSC::JSObject::prototypeChainMayInterceptStoreTo):
2142 * runtime/JSObject.h:
2143 (JSC::JSObject::finishCreation):
2144 (JSC::JSObject::getPrototypeDirect const):
2145 (JSC::JSObject::getPrototype):
2146 * runtime/JSObjectInlines.h:
2147 (JSC::JSObject::canPerformFastPutInline):
2148 (JSC::JSObject::getPropertySlot):
2149 (JSC::JSObject::getNonIndexPropertySlot):
2150 * runtime/JSProxy.cpp:
2151 (JSC::JSProxy::setTarget):
2152 * runtime/JSSet.cpp:
2153 (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
2154 * runtime/ProgramExecutable.cpp:
2155 (JSC::ProgramExecutable::initializeGlobalProperties):
2156 * runtime/StructureInlines.h:
2157 (JSC::Structure::isValid const):
2159 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2161 [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
2162 https://bugs.webkit.org/show_bug.cgi?id=178379
2164 Reviewed by Saam Barati.
2166 We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
2167 in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
2169 * bytecompiler/NodesCodegen.cpp:
2170 (JSC::BinaryOpNode::emitBytecode):
2172 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2174 [JSC] ScriptFetcher should be notified directly from module pipeline
2175 https://bugs.webkit.org/show_bug.cgi?id=178340
2177 Reviewed by Sam Weinig.
2179 Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
2180 We setup JSStdFunction to the resulted promise of the module pipeline. It is super
2181 ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
2182 JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
2184 But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
2185 notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
2186 from the module pipeline by observer style.
2188 This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
2189 completion/failure notifications from the module pipeline.
2191 * builtins/ModuleLoaderPrototype.js:
2193 (loadAndEvaluateModule):
2194 * runtime/Completion.cpp:
2196 * runtime/Completion.h:
2197 * runtime/JSModuleLoader.cpp:
2198 (JSC::jsValueToModuleKey):
2199 (JSC::JSModuleLoader::notifyCompleted):
2200 (JSC::JSModuleLoader::notifyFailed):
2201 * runtime/JSModuleLoader.h:
2202 * runtime/ModuleLoaderPrototype.cpp:
2203 (JSC::moduleLoaderPrototypeNotifyCompleted):
2204 (JSC::moduleLoaderPrototypeNotifyFailed):
2205 * runtime/ScriptFetcher.h:
2206 (JSC::ScriptFetcher::notifyLoadCompleted):
2207 (JSC::ScriptFetcher::notifyLoadFailed):
2209 2017-10-19 JF Bastien <jfbastien@apple.com>
2211 WebAssembly: no VM / JS version of everything but Instance
2212 https://bugs.webkit.org/show_bug.cgi?id=177473
2214 Reviewed by Filip Pizlo, Saam Barati.
2216 This change entails cleaning up and splitting a bunch of code which we had
2217 intertwined between C++ classes which represent JS objects, and pure C++
2218 implementation objects. This specific change goes most of the way towards
2219 allowing JSC's WebAssembly to work without VM / JS, up to but excluding
2220 JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
2221 yet). Because of this we still have a few FIXME identifying places that need to
2222 change. A follow-up change will go the rest of the way.
2224 I went about this change in the simplest way possible: grep the
2225 JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
2226 sub-directory (which contains the JS implementation of WebAssembly).
2228 None of this change removes the need for a JIT entitlement to be able to use
2229 WebAssembly. We don't have an interpreter, the process therefore still needs to
2230 be allowed to JIT to use these pure-C++ APIs.
2232 Interesting things to note:
2234 - Remove VM from Plan and associated places. It can just live as a capture in
2235 the callback lambda if it's needed.
2236 - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
2237 collect. We now instead pass two lambdas at construction time for this
2238 purpose: one to notify of memory pressure, and the other to ask for
2239 syncrhonous memory reclamation. This allows whoever creates the memory to
2240 dictate how to react to both these cases, and for a JS embedding that's to
2241 call the GC (async or sync, respectively).
2242 - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
2243 there, with an enum class for failure types.
2244 - Exceeding max on memory growth now returns a range error as per spec. This
2245 is a (very minor) breaking change: it used to throw OOM error. Update the
2247 - When generating the grow_memory opcode, no need to get the VM. Instead,
2248 reach directly for Wasm::Memory and grow it.
2249 - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
2250 ever called from JS (not from grow_memory as before).
2251 - Wasm::Memory now takes a callback for successful growth. This allows JS
2252 wrappers to register themselves when growth succeeds without Wasm::Memory
2253 knowning anything about JS. It'll also allow creating a list of callbacks
2254 for when we add thread support (we'll want to notify many wrappers, all
2256 - Wasm::Memory is now back to being the source of truth about address / size,
2257 used directly by generated code instead of JSWebAssemblyMemory.
2258 - Move wasmToJS from the general WasmBinding header to its own header under
2259 wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
2260 and therefore isn't general WebAssembly.
2261 - Make Wasm::Context an actual type (just a struct holding a
2262 JSWebAssemlyInstance for now) instead of an alias for that. Notably this
2263 doesn't add anything to the Context and doesn't change what actually gets
2264 passed around in JIT code (fast TLS or registers) because these changes
2265 potentially impact performance. The entire purpose of this change is to
2266 allow passing Wasm::Context around without having to know about VM. Since VM
2267 contains a Wasm::Context the JS embedding is effectively the same, but with
2268 this setup a non-JS embedding is much better off.
2269 - Move JSWebAssembly into the JS folder.
2270 - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
2271 - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
2272 being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
2273 stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
2274 called wasm->JS stub. This move means that the embedder must, after creating
2275 a Wasm::CodeBlock, somehow create the stubs to call back into the
2276 embedder. This removes an indirection in the generated code because
2277 the B3 IR generator now reaches into the instance instead of
2278 JSWebAssemblyCodeBlock.
2279 - Move more CodeBlock things. Compilation completion is now marked by its own
2280 atomic<bool> flag instead of a nullptr plan: that required using a lock, and
2281 was causing a deadlock in stack-trace.js because before my changes
2282 JSWebAssemblyCodeBlock did its own completion checking separately from
2283 Wasm::CodeBlock, without getting the lock. Now that everything points to
2284 Wasm::CodeBlock and there's no cached completion marker, the lock was being
2285 acquired in a sanity-check assertion.
2286 - Embedder -> Wasm wrappers are now generated through a function that's passed
2287 in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
2288 - WasmMemory doens't need to know about fault handling thunks. Only the IR
2289 generator should know, and should make sure that the exception throwing
2290 thunk is generated if any memory is present (note: with signal handling not
2291 all of them generate an exception check).
2292 - Make exception throwing pluggable: instead of having a hard-coded
2293 JS-specific lambda we now have a regular C++ function being called from JIT
2294 code when a WebAssembly exception is thrown. This allows any embedder to get
2295 called as they wish. For now a process can only have a single of these
2296 functions (i.e. only one embedder per process) because the trap handler is a
2297 singleton. That can be fixed in in #177475.
2298 - Create WasmEmbedder.h where all embedder plugging will live.
2299 - Split up JSWebAssemblyTable into Wasm::Table which is
2300 refcounted. JSWebAssemblyTable now only contains the JS functions in the
2301 table, and Wasm::Table is what's used by the JIT code to lookup where to
2302 call and do the instance check (for context switch). Note that this creates
2303 an extra allocation for all the instances in Wasm::Table, and in exchange
2304 removes an indirection in JIT code because the instance used to be obtained
2305 off of the JS function. Also note that it's the embedder than keeps the
2306 instances alive, not Wasm::Table (which holds a dumb pointer to the
2307 instance), because doing otherwise would cause reference cycles.
2308 - Add WasmInstance. It doesn't do much for now, owns globals.
2309 - JSWebAssembly instance now doesn't just contain the imported functions as
2310 JSObjects, it also has the corresponding import's instance and wasm
2311 entrypoint. This triples the space allocated per instance's imported
2312 function, but there shouldn't be that many imports. This has two upsides: it
2313 creates smaller and faster code, and makes is easier to disassociate
2314 embedder-specific things from embedder-neutral things. The small / faster
2315 win is in two places: B3 IR generator only needs offsetOfImportFunction for
2316 the call opcode (when the called index is an import) to know whether the
2317 import is wasm->wasm or wasm->embedder (this isn't known at compile-time
2318 because it's dependent on the import object), this is now done by seeing if
2319 that import function has an associated target instance (only wasm->wasm
2320 does); the other place is wasmBinding which uses offsetOfImportFunction to
2321 figure out the wasm->wasm target instance, and then gets
2322 WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
2323 call. The disassociation comes because the target instance can be
2324 Wasm::Instance once we change what the Context is, and
2325 WasmEntrypointLoadLocation is already embedder-independent. As a next step I
2326 can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
2327 and leave importFunction in as an opaque pointer which is embedder-specific,
2328 and in JS will remain WriteBarrier<JSObject>.
2329 - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
2330 around instead of VM. This is a first step in allowing entry frames which
2331 aren't stored on VM, but which are instead stored in an embedder-specific
2332 location. That change won't really affect JS except through code churn, but
2333 will allow WebAssembly to use some machinery in a generic manner without
2336 * JavaScriptCore.xcodeproj/project.pbxproj:
2338 * bytecode/PolymorphicAccess.cpp:
2339 (JSC::AccessGenerationState::emitExplicitExceptionHandler):
2340 * debugger/Debugger.cpp:
2341 (JSC::Debugger::stepOutOfFunction):
2342 (JSC::Debugger::returnEvent):
2343 (JSC::Debugger::unwindEvent):
2344 (JSC::Debugger::didExecuteProgram):
2345 * dfg/DFGJITCompiler.cpp:
2346 (JSC::DFG::JITCompiler::compileExceptionHandlers):
2347 * dfg/DFGOSREntry.cpp:
2348 (JSC::DFG::prepareOSREntry):
2349 * dfg/DFGOSRExit.cpp:
2350 (JSC::DFG::OSRExit::compileOSRExit):
2351 (JSC::DFG::OSRExit::compileExit):
2352 * dfg/DFGThunks.cpp:
2353 (JSC::DFG::osrEntryThunkGenerator):
2354 * ftl/FTLCompile.cpp:
2355 (JSC::FTL::compile):
2358 * ftl/FTLLowerDFGToB3.cpp:
2359 (JSC::FTL::DFG::LowerDFGToB3::lower):
2360 * ftl/FTLOSRExitCompiler.cpp:
2361 (JSC::FTL::compileStub):
2362 * interpreter/CallFrame.cpp:
2363 (JSC::CallFrame::wasmAwareLexicalGlobalObject):
2364 (JSC::CallFrame::callerFrame):
2365 (JSC::CallFrame::unsafeCallerFrame):
2366 * interpreter/CallFrame.h:
2367 (JSC::ExecState::callerFrame const):
2368 (JSC::ExecState::callerFrameOrEntryFrame const):
2369 (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
2370 * interpreter/FrameTracers.h:
2371 (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
2372 (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
2373 (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
2374 * interpreter/Interpreter.cpp:
2375 (JSC::UnwindFunctor::operator() const):
2376 (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
2377 (JSC::Interpreter::unwind):
2378 * interpreter/StackVisitor.cpp:
2379 (JSC::StackVisitor::StackVisitor):
2380 (JSC::StackVisitor::gotoNextFrame):
2381 (JSC::StackVisitor::readNonInlinedFrame):
2382 (JSC::StackVisitor::Frame::dump const):
2383 * interpreter/StackVisitor.h:
2384 (JSC::StackVisitor::Frame::callerIsEntryFrame const):
2385 * interpreter/VMEntryRecord.h:
2386 (JSC::VMEntryRecord::prevTopEntryFrame):
2387 (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
2388 (JSC::EntryFrame::vmEntryRecordOffset):
2389 * jit/AssemblyHelpers.cpp:
2390 (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
2391 (JSC::AssemblyHelpers::loadWasmContextInstance):
2392 (JSC::AssemblyHelpers::storeWasmContextInstance):
2393 (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
2394 (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
2395 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
2396 * jit/AssemblyHelpers.h:
2397 (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2398 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
2399 (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
2401 (JSC::JIT::emitEnterOptimizationCheck):
2402 (JSC::JIT::privateCompileExceptionHandlers):
2403 * jit/JITExceptions.cpp:
2404 (JSC::genericUnwind):
2405 * jit/JITOpcodes.cpp:
2406 (JSC::JIT::emit_op_throw):
2407 (JSC::JIT::emit_op_catch):
2408 (JSC::JIT::emitSlow_op_loop_hint):
2409 * jit/JITOpcodes32_64.cpp:
2410 (JSC::JIT::emit_op_throw):
2411 (JSC::JIT::emit_op_catch):
2412 * jit/JITOperations.cpp:
2413 * jit/ThunkGenerators.cpp:
2414 (JSC::throwExceptionFromCallSlowPathGenerator):
2415 (JSC::nativeForGenerator):
2417 (functionDumpCallFrame):
2418 * llint/LLIntSlowPaths.cpp:
2419 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2420 * llint/LLIntThunks.cpp:
2421 (JSC::vmEntryRecord):
2422 * llint/LowLevelInterpreter.asm:
2423 * llint/LowLevelInterpreter32_64.asm:
2424 * llint/LowLevelInterpreter64.asm:
2425 * runtime/Options.cpp:
2426 (JSC::recomputeDependentOptions):
2427 * runtime/Options.h:
2428 * runtime/SamplingProfiler.cpp:
2429 (JSC::FrameWalker::FrameWalker):
2430 (JSC::FrameWalker::advanceToParentFrame):
2431 (JSC::SamplingProfiler::processUnverifiedStackTraces):
2432 * runtime/ThrowScope.cpp:
2433 (JSC::ThrowScope::~ThrowScope):
2438 (JSC::VM::topEntryFrameOffset):
2439 * runtime/VMTraps.cpp:
2441 (JSC::VMTraps::tryInstallTrapBreakpoints):
2442 (JSC::VMTraps::invalidateCodeBlocksOnStack):
2443 * wasm/WasmB3IRGenerator.cpp:
2444 (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
2445 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2446 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2447 (JSC::Wasm::B3IRGenerator::addGrowMemory):
2448 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
2449 (JSC::Wasm::B3IRGenerator::addCall):
2450 (JSC::Wasm::B3IRGenerator::addCallIndirect):
2451 (JSC::Wasm::parseAndCompile):
2452 * wasm/WasmB3IRGenerator.h:
2453 * wasm/WasmBBQPlan.cpp:
2454 (JSC::Wasm::BBQPlan::BBQPlan):
2455 (JSC::Wasm::BBQPlan::compileFunctions):
2456 (JSC::Wasm::BBQPlan::complete):
2457 * wasm/WasmBBQPlan.h:
2458 * wasm/WasmBBQPlanInlines.h:
2459 (JSC::Wasm::BBQPlan::initializeCallees):
2460 * wasm/WasmBinding.cpp:
2461 (JSC::Wasm::wasmToWasm):
2462 * wasm/WasmBinding.h:
2463 * wasm/WasmCodeBlock.cpp:
2464 (JSC::Wasm::CodeBlock::create):
2465 (JSC::Wasm::CodeBlock::CodeBlock):
2466 (JSC::Wasm::CodeBlock::compileAsync):
2467 (JSC::Wasm::CodeBlock::setCompilationFinished):
2468 * wasm/WasmCodeBlock.h:
2469 (JSC::Wasm::CodeBlock::offsetOfImportStubs):
2470 (JSC::Wasm::CodeBlock::allocationSize):
2471 (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
2472 (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
2473 (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
2474 (JSC::Wasm::CodeBlock::compilationFinished):
2475 (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2476 (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2477 * wasm/WasmContext.cpp:
2478 (JSC::Wasm::Context::useFastTLS):
2479 (JSC::Wasm::Context::load const):
2480 (JSC::Wasm::Context::store):
2481 * wasm/WasmContext.h:
2482 * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
2483 * wasm/WasmFaultSignalHandler.cpp:
2484 * wasm/WasmFaultSignalHandler.h:
2485 * wasm/WasmFormat.h:
2486 * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2487 (JSC::Wasm::Instance::Instance):
2488 (JSC::Wasm::Instance::~Instance):
2489 (JSC::Wasm::Instance::extraMemoryAllocated const):
2490 * wasm/WasmInstance.h: Added.
2491 (JSC::Wasm::Instance::create):
2492 (JSC::Wasm::Instance::finalizeCreation):
2493 (JSC::Wasm::Instance::module):
2494 (JSC::Wasm::Instance::codeBlock):
2495 (JSC::Wasm::Instance::memory):
2496 (JSC::Wasm::Instance::table):
2497 (JSC::Wasm::Instance::loadI32Global const):
2498 (JSC::Wasm::Instance::loadI64Global const):
2499 (JSC::Wasm::Instance::loadF32Global const):
2500 (JSC::Wasm::Instance::loadF64Global const):
2501 (JSC::Wasm::Instance::setGlobal):
2502 (JSC::Wasm::Instance::offsetOfCachedStackLimit):
2503 (JSC::Wasm::Instance::cachedStackLimit const):
2504 (JSC::Wasm::Instance::setCachedStackLimit):
2505 * wasm/WasmMemory.cpp:
2506 (JSC::Wasm::Memory::Memory):
2507 (JSC::Wasm::Memory::create):
2508 (JSC::Wasm::Memory::~Memory):
2509 (JSC::Wasm::Memory::grow):
2510 * wasm/WasmMemory.h:
2511 (JSC::Wasm::Memory::offsetOfMemory):
2512 (JSC::Wasm::Memory::offsetOfSize):
2513 * wasm/WasmMemoryInformation.cpp:
2514 (JSC::Wasm::PinnedRegisterInfo::get):
2515 (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
2516 * wasm/WasmMemoryInformation.h:
2517 (JSC::Wasm::PinnedRegisterInfo::toSave const):
2518 * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2519 (JSC::Wasm::makeString):
2520 * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2521 * wasm/WasmModule.cpp:
2522 (JSC::Wasm::makeValidationCallback):
2523 (JSC::Wasm::Module::validateSync):
2524 (JSC::Wasm::Module::validateAsync):
2525 (JSC::Wasm::Module::getOrCreateCodeBlock):
2526 (JSC::Wasm::Module::compileSync):
2527 (JSC::Wasm::Module::compileAsync):
2528 * wasm/WasmModule.h:
2529 * wasm/WasmModuleParser.cpp:
2530 (JSC::Wasm::ModuleParser::parseTableHelper):
2531 * wasm/WasmOMGPlan.cpp:
2532 (JSC::Wasm::OMGPlan::OMGPlan):
2533 (JSC::Wasm::OMGPlan::runForIndex):
2534 * wasm/WasmOMGPlan.h:
2535 * wasm/WasmPageCount.h:
2536 (JSC::Wasm::PageCount::isValid const):
2537 * wasm/WasmPlan.cpp:
2538 (JSC::Wasm::Plan::Plan):
2539 (JSC::Wasm::Plan::runCompletionTasks):
2540 (JSC::Wasm::Plan::addCompletionTask):
2541 (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
2543 (JSC::Wasm::Plan::dontFinalize):
2544 * wasm/WasmSignature.cpp:
2545 * wasm/WasmSignature.h:
2546 * wasm/WasmTable.cpp: Added.
2547 (JSC::Wasm::Table::create):
2548 (JSC::Wasm::Table::~Table):
2549 (JSC::Wasm::Table::Table):
2550 (JSC::Wasm::Table::grow):
2551 (JSC::Wasm::Table::clearFunction):
2552 (JSC::Wasm::Table::setFunction):
2553 * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
2554 (JSC::Wasm::Table::maximum const):
2555 (JSC::Wasm::Table::size const):
2556 (JSC::Wasm::Table::offsetOfSize):
2557 (JSC::Wasm::Table::offsetOfFunctions):
2558 (JSC::Wasm::Table::offsetOfInstances):
2559 (JSC::Wasm::Table::isValidSize):
2560 * wasm/WasmThunks.cpp:
2561 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2562 (JSC::Wasm::triggerOMGTierUpThunkGenerator):
2563 (JSC::Wasm::Thunks::setThrowWasmException):
2564 (JSC::Wasm::Thunks::throwWasmException):
2565 * wasm/WasmThunks.h:
2566 * wasm/WasmWorklist.cpp:
2567 (JSC::Wasm::Worklist::stopAllPlansForContext):
2568 * wasm/WasmWorklist.h:
2569 * wasm/js/JSToWasm.cpp: Added.
2570 (JSC::Wasm::createJSToWasmWrapper):
2571 * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2572 * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
2573 * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
2574 * wasm/js/JSWebAssemblyCodeBlock.cpp:
2575 (JSC::JSWebAssemblyCodeBlock::create):
2576 (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2577 * wasm/js/JSWebAssemblyCodeBlock.h:
2578 * wasm/js/JSWebAssemblyInstance.cpp:
2579 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2580 (JSC::JSWebAssemblyInstance::finishCreation):
2581 (JSC::JSWebAssemblyInstance::visitChildren):
2582 (JSC::JSWebAssemblyInstance::finalizeCreation):
2583 (JSC::JSWebAssemblyInstance::create):
2584 * wasm/js/JSWebAssemblyInstance.h:
2585 (JSC::JSWebAssemblyInstance::instance):
2586 (JSC::JSWebAssemblyInstance::context const):
2587 (JSC::JSWebAssemblyInstance::table):
2588 (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2589 (JSC::JSWebAssemblyInstance::setMemory):
2590 (JSC::JSWebAssemblyInstance::offsetOfTail):
2591 (JSC::JSWebAssemblyInstance::importFunctionInfo):
2592 (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
2593 (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
2594 (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
2595 (JSC::JSWebAssemblyInstance::importFunction):
2596 (JSC::JSWebAssemblyInstance::internalMemory):
2597 (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
2598 (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
2599 (JSC::JSWebAssemblyInstance::offsetOfCallee):
2600 (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2601 (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
2602 (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
2603 (JSC::JSWebAssemblyInstance::cachedStackLimit const):
2604 (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2605 (JSC::JSWebAssemblyInstance::wasmMemory):
2606 (JSC::JSWebAssemblyInstance::wasmModule):
2607 (JSC::JSWebAssemblyInstance::allocationSize):
2608 (JSC::JSWebAssemblyInstance::module const):
2609 * wasm/js/JSWebAssemblyMemory.cpp:
2610 (JSC::JSWebAssemblyMemory::create):
2611 (JSC::JSWebAssemblyMemory::adopt):
2612 (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
2613 (JSC::JSWebAssemblyMemory::grow):
2614 (JSC::JSWebAssemblyMemory::growSuccessCallback):
2615 * wasm/js/JSWebAssemblyMemory.h:
2616 * wasm/js/JSWebAssemblyModule.cpp:
2617 (JSC::JSWebAssemblyModule::moduleInformation const):
2618 (JSC::JSWebAssemblyModule::exportSymbolTable const):
2619 (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
2620 (JSC::JSWebAssemblyModule::callee const):
2621 (JSC::JSWebAssemblyModule::codeBlock):
2622 (JSC::JSWebAssemblyModule::module):
2623 * wasm/js/JSWebAssemblyModule.h:
2624 * wasm/js/JSWebAssemblyTable.cpp:
2625 (JSC::JSWebAssemblyTable::create):
2626 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2627 (JSC::JSWebAssemblyTable::visitChildren):
2628 (JSC::JSWebAssemblyTable::grow):
2629 (JSC::JSWebAssemblyTable::getFunction):
2630 (JSC::JSWebAssemblyTable::clearFunction):
2631 (JSC::JSWebAssemblyTable::setFunction):
2632 * wasm/js/JSWebAssemblyTable.h:
2633 (JSC::JSWebAssemblyTable::isValidSize):
2634 (JSC::JSWebAssemblyTable::maximum const):
2635 (JSC::JSWebAssemblyTable::size const):
2636 (JSC::JSWebAssemblyTable::table):
2637 * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
2638 (JSC::Wasm::materializeImportJSCell):
2639 (JSC::Wasm::wasmToJS):
2640 (JSC::Wasm::wasmToJSException):
2641 * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2642 * wasm/js/WebAssemblyFunction.cpp:
2643 (JSC::callWebAssemblyFunction):
2644 * wasm/js/WebAssemblyInstanceConstructor.cpp:
2645 (JSC::constructJSWebAssemblyInstance):
2646 * wasm/js/WebAssemblyMemoryConstructor.cpp:
2647 (JSC::constructJSWebAssemblyMemory):
2648 * wasm/js/WebAssemblyMemoryPrototype.cpp:
2649 (JSC::webAssemblyMemoryProtoFuncGrow):
2650 * wasm/js/WebAssemblyModuleConstructor.cpp:
2651 (JSC::constructJSWebAssemblyModule):
2652 (JSC::WebAssemblyModuleConstructor::createModule):
2653 * wasm/js/WebAssemblyModuleConstructor.h:
2654 * wasm/js/WebAssemblyModuleRecord.cpp:
2655 (JSC::WebAssemblyModuleRecord::link):
2656 (JSC::WebAssemblyModuleRecord::evaluate):
2657 * wasm/js/WebAssemblyPrototype.cpp:
2658 (JSC::webAssemblyCompileFunc):
2660 (JSC::compileAndInstantiate):
2661 (JSC::webAssemblyValidateFunc):
2662 * wasm/js/WebAssemblyTableConstructor.cpp:
2663 (JSC::constructJSWebAssemblyTable):
2664 * wasm/js/WebAssemblyWrapperFunction.cpp:
2665 (JSC::WebAssemblyWrapperFunction::create):
2667 2017-10-19 Mark Lam <mark.lam@apple.com>
2669 Stringifier::appendStringifiedValue() is missing an exception check.
2670 https://bugs.webkit.org/show_bug.cgi?id=178386
2671 <rdar://problem/35027610>
2673 Reviewed by Saam Barati.
2675 * runtime/JSONObject.cpp:
2676 (JSC::Stringifier::appendStringifiedValue):
2678 2017-10-19 Saam Barati <sbarati@apple.com>
2680 REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
2681 https://bugs.webkit.org/show_bug.cgi?id=178543
2683 Reviewed by Filip Pizlo.
2685 * dfg/DFGByteCodeParser.cpp:
2686 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2688 2017-10-19 Saam Barati <sbarati@apple.com>
2690 re-inline ObjectAllocationProfile::initializeProfile
2691 https://bugs.webkit.org/show_bug.cgi?id=178532
2693 Rubber stamped by Michael Saboff.
2695 I un-inlined this function when implementing poly proto.
2696 This patch re-inlines it. In my testing, it looks like it
2697 might be a 0.5% speedometer progression to inline it.
2699 * JavaScriptCore.xcodeproj/project.pbxproj:
2701 * bytecode/CodeBlock.cpp:
2702 * bytecode/ObjectAllocationProfile.cpp: Removed.
2703 * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
2704 (JSC::ObjectAllocationProfile::initializeProfile):
2705 (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
2706 * runtime/FunctionRareData.cpp:
2708 2017-10-19 Michael Saboff <msaboff@apple.com>
2710 Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
2711 https://bugs.webkit.org/show_bug.cgi?id=178521
2713 Reviewed by JF Bastien.
2715 * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
2716 standard version. The prior version was the draft 6.0 version.
2718 2017-10-19 Saam Barati <sbarati@apple.com>
2720 We should hard code the poly proto offset
2721 https://bugs.webkit.org/show_bug.cgi?id=178531
2723 Reviewed by Filip Pizlo.
2725 This patch embraces that the poly proto offset is always zero. It's already
2726 the case that we would always get the inline offset zero for poly proto just
2727 by construction. This just hardcodes this assumption throughout the codebase.
2728 This appears to be a 1% speedometer progression in my testing.
2730 The downside of this patch is that it may require changing how we do
2731 things when we implement poly proto when inheriting from builtin
2732 types. I think we can face this problem when we decide to implement
2735 * bytecode/AccessCase.cpp:
2736 (JSC::AccessCase::generateWithGuard):
2737 * dfg/DFGOperations.cpp:
2738 * dfg/DFGSpeculativeJIT.cpp:
2739 (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2740 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2741 * ftl/FTLLowerDFGToB3.cpp:
2742 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2743 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2744 * jit/JITOpcodes.cpp:
2745 (JSC::JIT::emit_op_instanceof):
2746 * jit/JITOpcodes32_64.cpp:
2747 (JSC::JIT::emit_op_instanceof):
2748 * runtime/CommonSlowPaths.cpp:
2749 (JSC::SLOW_PATH_DECL):
2750 * runtime/JSObject.cpp:
2751 (JSC::JSObject::setPrototypeDirect):
2752 * runtime/JSObject.h:
2753 (JSC::JSObject::locationForOffset const):
2754 (JSC::JSObject::locationForOffset):
2755 (JSC::JSObject::getDirect const):
2756 * runtime/PropertyOffset.h:
2757 * runtime/Structure.cpp:
2758 (JSC::Structure::create):
2759 (JSC::Structure::dump const):
2760 * runtime/Structure.h:
2761 * runtime/StructureInlines.h:
2762 (JSC::Structure::storedPrototype const):
2763 (JSC::Structure::storedPrototypeObject const):
2765 2017-10-19 Saam Barati <sbarati@apple.com>
2767 Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
2768 https://bugs.webkit.org/show_bug.cgi?id=178529
2770 Reviewed by Mark Lam.
2772 * runtime/Structure.h:
2773 * runtime/StructureInlines.h:
2774 (JSC::Structure::storedPrototypeObject const):
2775 (JSC::Structure::storedPrototypeStructure const):
2776 (JSC::Structure::storedPrototype const):
2777 (JSC::Structure::prototypeForLookup const):
2778 (JSC::Structure::prototypeChain const):
2780 2017-10-19 Saam Barati <sbarati@apple.com>
2782 Turn poly proto back on by default and remove the option
2783 https://bugs.webkit.org/show_bug.cgi?id=178525
2785 Reviewed by Mark Lam.
2787 I added this option because I thought it'd speed speedometer up because the
2788 original poly proto patch slowed speedometer down. It turns out that
2789 allocating poly proto objects is not what slows speedometer down. It's
2790 other code I added in the runtime that needs to be poly proto aware. I'll
2791 be addressing these in follow up patches.
2793 * runtime/Options.h:
2794 * runtime/StructureInlines.h:
2795 (JSC::Structure::shouldConvertToPolyProto):
2797 2017-10-19 Robin Morisset <rmorisset@apple.com>
2799 Turn recursive tail calls into loops
2800 https://bugs.webkit.org/show_bug.cgi?id=176601
2802 Reviewed by Saam Barati.
2804 We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
2805 One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
2806 Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
2807 We do this part through modifying the computation of the jump targets.
2808 Importantly, we only do this splitting for functions that have tail calls.
2809 It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
2811 We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
2812 The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
2814 * bytecode/CodeBlock.h:
2815 (JSC::CodeBlock::hasTailCalls const):
2816 * bytecode/PreciseJumpTargets.cpp:
2817 (JSC::getJumpTargetsForBytecodeOffset):
2818 (JSC::computePreciseJumpTargetsInternal):
2819 * bytecode/UnlinkedCodeBlock.cpp:
2820 (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2821 * bytecode/UnlinkedCodeBlock.h:
2822 (JSC::UnlinkedCodeBlock::hasTailCalls const):
2823 (JSC::UnlinkedCodeBlock::setHasTailCalls):
2824 * bytecompiler/BytecodeGenerator.cpp:
2825 (JSC::BytecodeGenerator::emitEnter):
2826 (JSC::BytecodeGenerator::emitCallInTailPosition):
2827 * dfg/DFGByteCodeParser.cpp:
2828 (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
2829 (JSC::DFG::ByteCodeParser::makeBlockTargetable):
2830 (JSC::DFG::ByteCodeParser::handleCall):
2831 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2832 (JSC::DFG::ByteCodeParser::parseBlock):
2833 (JSC::DFG::ByteCodeParser::parse):
2835 2017-10-18 Mark Lam <mark.lam@apple.com>
2837 RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
2838 https://bugs.webkit.org/show_bug.cgi?id=177600
2839 <rdar://problem/34710985>
2841 Reviewed by Saam Barati.
2843 According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
2844 section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
2845 descriptor value is present.
2847 * runtime/RegExpObject.cpp:
2848 (JSC::RegExpObject::defineOwnProperty):
2850 2017-10-18 Keith Miller <keith_miller@apple.com>
2852 Setup WebCore build to start using unified sources.
2853 https://bugs.webkit.org/show_bug.cgi?id=178362
2855 Reviewed by Tim Horton.
2857 Change comments in source list files. Also, pass explicit names for build files.
2860 * PlatformGTK.cmake:
2861 * PlatformMac.cmake:
2866 2017-10-18 Commit Queue <commit-queue@webkit.org>
2868 Unreviewed, rolling out r223321.
2869 https://bugs.webkit.org/show_bug.cgi?id=178476
2871 This protocol change broke some internal builds (Requested by
2872 brrian__ on #webkit).
2876 "Web Inspector: provide a way to enable/disable event
2878 https://bugs.webkit.org/show_bug.cgi?id=177451
2879 https://trac.webkit.org/changeset/223321
2881 2017-10-18 Mark Lam <mark.lam@apple.com>
2883 The compiler should always register a structure when it adds its transitionWatchPointSet.
2884 https://bugs.webkit.org/show_bug.cgi?id=178420
2885 <rdar://problem/34814024>
2887 Reviewed by Saam Barati and Filip Pizlo.
2889 Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
2890 now invoke Graph::registerAndWatchStructureTransition() on the structure.
2891 registerAndWatchStructureTransition() both registers the structure and add its
2892 transitionWatchpointSet to the plan desired watchpoints.
2894 Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
2895 except registerAndWatchStructureTransition() adds the structure's
2896 transitionWatchpointSet unconditionally.
2898 * dfg/DFGArgumentsEliminationPhase.cpp:
2899 * dfg/DFGArrayMode.cpp:
2900 (JSC::DFG::ArrayMode::refine const):
2901 * dfg/DFGByteCodeParser.cpp:
2902 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2903 * dfg/DFGFixupPhase.cpp:
2904 (JSC::DFG::FixupPhase::fixupNode):
2907 (JSC::DFG::Graph::registerAndWatchStructureTransition):
2910 * dfg/DFGSpeculativeJIT.cpp:
2911 (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2912 - The second set of addLazily()s is redundant. This set is executed only when
2913 prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
2914 only if we've executed the if statement above it. That preceding if statement
2915 already registerAndWatchStructureTransition() the same 2 structures. Hence,
2916 this second set can be deleted.
2918 * dfg/DFGWatchpointCollectionPhase.cpp:
2919 (JSC::DFG::WatchpointCollectionPhase::addLazily):
2920 - Deleted an unused function.
2922 * ftl/FTLLowerDFGToB3.cpp:
2923 (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2925 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
2927 [JSC] Remove unused private name structure
2928 https://bugs.webkit.org/show_bug.cgi?id=178436
2930 Reviewed by Sam Weinig.
2932 It is no longer used. This patch just removes it.
2934 * runtime/JSGlobalObject.h:
2935 (JSC::JSGlobalObject::numberObjectStructure const):
2936 (JSC::JSGlobalObject::privateNameStructure const): Deleted.
2938 2017-10-18 Ryosuke Niwa <rniwa@webkit.org>
2940 Fix macOS and iOS builds after r223594.
2942 * JavaScriptCore.xcodeproj/project.pbxproj:
2944 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
2946 [JSC] __proto__ getter should be fast
2947 https://bugs.webkit.org/show_bug.cgi?id=178067
2949 Reviewed by Saam Barati.
2951 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2952 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2953 Call node for this. It is inefficient since typically we know the `prototype` of the given
2954 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2955 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2956 we can still change this to efficient access to poly proto slot.
2958 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2959 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2960 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2961 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2962 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2965 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2967 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2968 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2969 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2971 This patch improves SixSpeed super.es6 by 3.42x.
2975 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
2977 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2979 * dfg/DFGAbstractInterpreterInlines.h:
2980 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2981 * dfg/DFGByteCodeParser.cpp:
2982 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2983 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2984 (JSC::DFG::ByteCodeParser::handleGetById):
2985 * dfg/DFGClobberize.h:
2986 (JSC::DFG::clobberize):
2987 * dfg/DFGDoesGC.cpp:
2989 * dfg/DFGFixupPhase.cpp:
2990 (JSC::DFG::FixupPhase::fixupNode):
2991 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2992 * dfg/DFGHeapLocation.cpp:
2993 (WTF::printInternal):
2994 * dfg/DFGHeapLocation.h:
2996 (JSC::DFG::Node::hasHeapPrediction):
2997 (JSC::DFG::Node::shouldSpeculateFunction):
2998 * dfg/DFGNodeType.h:
2999 * dfg/DFGOperations.cpp:
3000 * dfg/DFGOperations.h:
3001 * dfg/DFGPredictionPropagationPhase.cpp:
3002 * dfg/DFGSafeToExecute.h:
3003 (JSC::DFG::safeToExecute):
3004 * dfg/DFGSpeculativeJIT.cpp:
3005 (JSC::DFG::SpeculativeJIT::speculateFunction):
3006 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
3007 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
3008 * dfg/DFGSpeculativeJIT.h:
3009 (JSC::DFG::SpeculativeJIT::callOperation):
3010 * dfg/DFGSpeculativeJIT32_64.cpp:
3011 (JSC::DFG::SpeculativeJIT::compile):
3012 * dfg/DFGSpeculativeJIT64.cpp:
3013 (JSC::DFG::SpeculativeJIT::compile):
3014 * ftl/FTLCapabilities.cpp:
3015 (JSC::FTL::canCompile):
3016 * ftl/FTLLowerDFGToB3.cpp:
3017 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3018 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
3019 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3020 * jit/IntrinsicEmitter.cpp:
3021 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
3022 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
3023 * jit/JITOperations.h:
3024 * runtime/Intrinsic.cpp:
3025 (JSC::intrinsicName):
3026 * runtime/Intrinsic.h:
3027 * runtime/JSGlobalObject.cpp:
3028 (JSC::JSGlobalObject::init):
3029 * runtime/JSGlobalObject.h:
3030 (JSC::JSGlobalObject::booleanPrototype const):
3031 (JSC::JSGlobalObject::numberPrototype const):
3032 (JSC::JSGlobalObject::booleanObjectStructure const):
3033 * runtime/JSGlobalObjectFunctions.cpp:
3034 (JSC::globalFuncProtoGetter):
3035 * runtime/JSGlobalObjectFunctions.h:
3036 * runtime/ObjectConstructor.cpp:
3037 * runtime/ReflectObject.cpp:
3039 2017-10-17 Ryan Haddad <ryanhaddad@apple.com>
3041 Unreviewed, rolling out r223523.
3043 A test for this change is failing on debug JSC bots.
3047 "[JSC] __proto__ getter should be fast"
3048 https://bugs.webkit.org/show_bug.cgi?id=178067
3049 https://trac.webkit.org/changeset/223523
3051 2017-10-17 Youenn Fablet <youenn@apple.com>
3053 Add preliminary support for fetch event
3054 https://bugs.webkit.org/show_bug.cgi?id=178171
3056 Reviewed by Chris Dumez.
3060 * runtime/JSPromise.h:
3062 2017-10-10 Yusuke Suzuki <utatane.tea@gmail.com>
3064 [JSC] __proto__ getter should be fast
3065 https://bugs.webkit.org/show_bug.cgi?id=178067
3067 Reviewed by Saam Barati.
3069 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
3070 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
3071 Call node for this. It is inefficient since typically we know the `prototype` of the given
3072 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
3073 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
3074 we can still change this to efficient access to poly proto slot.
3076 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
3077 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
3078 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
3079 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
3080 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
3083 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
3085 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
3086 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
3087 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
3089 This patch improves SixSpeed super.es6 by 3.42x.
3093 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
3095 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
3097 * dfg/DFGAbstractInterpreterInlines.h:
3098 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3099 * dfg/DFGByteCodeParser.cpp:
3100 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3101 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
3102 (JSC::DFG::ByteCodeParser::handleGetById):
3103 * dfg/DFGClobberize.h:
3104 (JSC::DFG::clobberize):
3105 * dfg/DFGDoesGC.cpp:
3107 * dfg/DFGFixupPhase.cpp:
3108 (JSC::DFG::FixupPhase::fixupNode):
3109 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
3110 * dfg/DFGHeapLocation.cpp:
3111 (WTF::printInternal):
3112 * dfg/DFGHeapLocation.h:
3114 (JSC::DFG::Node::hasHeapPrediction):
3115 (JSC::DFG::Node::shouldSpeculateFunction):
3116 * dfg/DFGNodeType.h:
3117 * dfg/DFGOperations.cpp:
3118 * dfg/DFGOperations.h:
3119 * dfg/DFGPredictionPropagationPhase.cpp:
3120 * dfg/DFGSafeToExecute.h:
3121 (JSC::DFG::safeToExecute):
3122 * dfg/DFGSpeculativeJIT.cpp:
3123 (JSC::DFG::SpeculativeJIT::speculateFunction):
3124 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
3125 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
3126 * dfg/DFGSpeculativeJIT.h:
3127 * dfg/DFGSpeculativeJIT32_64.cpp:
3128 (JSC::DFG::SpeculativeJIT::compile):
3129 * dfg/DFGSpeculativeJIT64.cpp:
3130 (JSC::DFG::SpeculativeJIT::compile):
3131 * ftl/FTLCapabilities.cpp:
3132 (JSC::FTL::canCompile):
3133 * ftl/FTLLowerDFGToB3.cpp:
3134 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3135 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
3136 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3137 * jit/IntrinsicEmitter.cpp:
3138 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
3139 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
3140 * runtime/Intrinsic.cpp:
3141 (JSC::intrinsicName):
3142 * runtime/Intrinsic.h:
3143 * runtime/JSGlobalObject.cpp:
3144 (JSC::JSGlobalObject::init):
3145 * runtime/JSGlobalObjectFunctions.cpp:
3146 (JSC::globalFuncProtoGetter):
3147 * runtime/JSGlobalObjectFunctions.h:
3148 * runtime/ObjectConstructor.cpp:
3149 * runtime/ReflectObject.cpp:
3151 2017-10-17 Keith Miller <keith_miller@apple.com>
3153 Change WebCore sources to work with unified source builds
3154 https://bugs.webkit.org/show_bug.cgi?id=178229
3156 Rubber stamped by Tim Horton.
3158 * Configurations/FeatureDefines.xcconfig:
3160 2017-10-15 Filip Pizlo <fpizlo@apple.com>
3162 Make some asserts into release asserts
3163 https://bugs.webkit.org/show_bug.cgi?id=178324
3165 Reviewed by Saam Barati.
3167 These asserts are not on perf critical paths, so they might as well be release asserts.
3169 * runtime/DataView.h:
3170 (JSC::DataView::get):
3171 (JSC::DataView::set):
3173 2017-10-16 JF Bastien <jfbastien@apple.com>
3175 JSRunLoopTimer: reduce likely race when used improperly
3176 https://bugs.webkit.org/show_bug.cgi?id=178298
3177 <rdar://problem/32899816>
3179 Reviewed by Saam Barati.
3181 If an API user sets a timer on JSRunLoopTimer, and then racily
3182 destroys the JSRunLoopTimer while the timer is firing then it's
3183 possible for timerDidFire to cause a use-after-free and / or crash
3184 because e.g. m_apiLock becomes a nullptr while timerDidFire is
3185 executing. That results from an invalid use of JSRunLoopTimer, but
3186 we should try to be more resilient for that type of misuse because
3187 it's not necessarily easy to catch by inspection.
3189 With this change the only remaining race is if the timer fires,
3190 and then only timerDidFire's prologue executes, but not the load
3191 of the m_apiLock pointer from `this`. It's a much smaller race.
3193 Separately, I'll reach out to API users who are seemingly misusing
3196 * runtime/JSRunLoopTimer.cpp:
3197 (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
3198 and checks for nullptr. This prevents loading it twice off of
3199 `this` and turns a nullptr deref into "just" a use-after-free.
3200 (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
3201 calling m_vm->unregisterRunLoopTimer(this), which in turn does
3202 CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
3203 timerDidFire from doing much while the timers are un-registered.
3204 ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
3205 releasing the lock, so it needs its own local copy.
3207 2017-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
3209 [JSC] Perform module specifier validation at parsing time
3210 https://bugs.webkit.org/show_bug.cgi?id=178256
3212 Reviewed by Darin Adler.
3214 This patch make module loader's `resolve` operation synchronous. And we validate
3215 module's requested module names when instantiating the module instead of satisfying
3216 module's dependencies. This change is not observable to users. But this is precise
3217 to the spec and this optimizes & simplifies the current module loader a bit by
3218 reducing object allocations.
3220 Previously, we have an object called pair in the module loader. This is pair of
3221 module's name and module's record. And we use it to link one module to dependent
3222 modules. Now, it is replaced with module's registry entry.
3224 We also change our loader functions to take a registry entry instead of a module key.
3225 Previous design is due to the consideration that these APIs may be exposed to users
3226 in whatwg/loader spec. However, this won't happen. This change removes unnecessary
3227 repeatedly hash map lookups.
3229 * builtins/ModuleLoaderPrototype.js:
3230 (globalPrivate.newRegistryEntry):
3232 (requestInstantiate):
3238 (GlobalObject::moduleLoaderResolve):
3239 * runtime/AbstractModuleRecord.cpp:
3240 (JSC::AbstractModuleRecord::finishCreation):
3241 (JSC::AbstractModuleRecord::hostResolveImportedModule):
3242 * runtime/JSGlobalObject.h:
3243 * runtime/JSModuleLoader.cpp:
3244 (JSC::JSModuleLoader::resolveSync):
3245 (JSC::JSModuleLoader::resolve):
3246 * runtime/JSModuleLoader.h:
3247 * runtime/ModuleLoaderPrototype.cpp:
3248 (JSC::moduleLoaderPrototypeResolveSync):
3250 2017-10-14 Devin Rousso <webkit@devinrousso.com>
3252 Web Inspector: provide a way to enable/disable event listeners
3253 https://bugs.webkit.org/show_bug.cgi?id=177451
3255 Reviewed by Joseph Pecoraro.
3257 * inspector/protocol/DOM.json:
3258 Add `setEventListenerDisabled` command that enables/disables a specific event listener
3259 during event dispatch. When a disabled event listener is fired, the listener's callback will
3262 2017-10-14 Yusuke Suzuki <utatane.tea@gmail.com>
3264 Reland "Add Above/Below comparisons for UInt32 patterns"
3265 https://bugs.webkit.org/show_bug.cgi?id=177281
3267 Reviewed by Saam Barati.
3269 We reland this patch without DFGStrengthReduction change to see what causes
3270 regression in the iOS bot.
3272 Sometimes, we would like to have UInt32 operations in JS. While VM does
3273 not support UInt32 nicely, VM supports efficient Int32 operations. As long
3274 as signedness does not matter, we can just perform Int32 operations instead
3275 and recognize its bit pattern as UInt32.
3277 But of course, some operations respect signedness. The most frequently
3278 used one is comparison. Octane/zlib performs UInt32 comparison by performing
3279 `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
3280 UInt32 in Int32 form. And op_unsigned will generate Double value if
3281 the generated Int32 is < 0 (which should be UInt32).
3283 There is a chance for optimization. The given code pattern is the following.
3285 op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
3287 This can be converted to the following.
3289 op_urshift(@1) below:< op_urshift(@2)
3291 The above conversion is nice since
3293 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
3294 this check depends on the value of Int32, dropping this check is not as easy as
3295 removing Int32 edge filters.
3297 2. We can perform unsigned comparison in Int32 form. We do not need to convert
3300 Since the above comparison exists in Octane/zlib's *super* hot path, dropping
3301 op_unsigned offers huge win.
3303 At first, my patch attempts to convert the above thing in DFG pipeline.
3304 However it poses several problems.
3306 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
3307 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
3309 2: UInt32ToNumber(@0)
3311 4: UInt32ToNumber(@1)
3314 we could drop @5's MovHint. But @3 is difficult since @4 can exit.
3316 So, instead, we start introducing a simple optimization in the bytecode compiler.
3317 It performs pattern matching for op_urshift and comparison to drop op_unsigned.
3318 We adds op_below and op_above families to bytecodes. They only accept Int32 and
3319 perform unsigned comparison.
3321 This offers 4% performance improvement in Octane/zlib.
3325 zlib x2 431.07483+-16.28434 414.33407+-9.38375 might be 1.0404x faster
3327 * bytecode/BytecodeDumper.cpp:
3328 (JSC::BytecodeDumper<Block>::printCompareJump):
3329 (JSC::BytecodeDumper<Block>::dumpBytecode):
3330 * bytecode/BytecodeDumper.h:
3331 * bytecode/BytecodeList.json:
3332 * bytecode/BytecodeUseDef.h:
3333 (JSC::computeUsesForBytecodeOffset):
3334 (JSC::computeDefsForBytecodeOffset):
3335 * bytecode/Opcode.h:
3337 * bytecode/PreciseJumpTargetsInlines.h:
3338 (JSC::extractStoredJumpTargetsForBytecodeOffset):
3339 * bytecompiler/BytecodeGenerator.cpp:
3340 (JSC::BytecodeGenerator::emitJumpIfTrue):
3341 (JSC::BytecodeGenerator::emitJumpIfFalse):
3342 * bytecompiler/NodesCodegen.cpp:
3343 (JSC::BinaryOpNode::emitBytecode):
3344 * dfg/DFGAbstractInterpreterInlines.h:
3345 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3346 * dfg/DFGByteCodeParser.cpp:
3347 (JSC::DFG::ByteCodeParser::parseBlock):
3348 * dfg/DFGCapabilities.cpp:
3349 (JSC::DFG::capabilityLevel):
3350 * dfg/DFGClobberize.h:
3351 (JSC::DFG::clobberize):
3352 * dfg/DFGDoesGC.cpp:
3354 * dfg/DFGFixupPhase.cpp:
3355 (JSC::DFG::FixupPhase::fixupNode):
3356 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3357 * dfg/DFGNodeType.h:
3358 * dfg/DFGPredictionPropagationPhase.cpp:
3359 * dfg/DFGSafeToExecute.h:
3360 (JSC::DFG::safeToExecute):
3361 * dfg/DFGSpeculativeJIT.cpp:
3362 (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
3363 * dfg/DFGSpeculativeJIT.h:
3364 * dfg/DFGSpeculativeJIT32_64.cpp:
3365 (JSC::DFG::SpeculativeJIT::compile):
3366 * dfg/DFGSpeculativeJIT64.cpp:
3367 (JSC::DFG::SpeculativeJIT::compile):
3368 * dfg/DFGValidate.cpp:
3369 * ftl/FTLCapabilities.cpp:
3370 (JSC::FTL::canCompile):
3371 * ftl/FTLLowerDFGToB3.cpp:
3372 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3373 (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
3374 (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
3376 (JSC::JIT::privateCompileMainPass):
3378 * jit/JITArithmetic.cpp:
3379 (JSC::JIT::emit_op_below):
3380 (JSC::JIT::emit_op_beloweq):
3381 (JSC::JIT::emit_op_jbelow):
3382 (JSC::JIT::emit_op_jbeloweq):
3383 (JSC::JIT::emit_compareUnsignedAndJump):
3384 (JSC::JIT::emit_compareUnsigned):
3385 * jit/JITArithmetic32_64.cpp:
3386 (JSC::JIT::emit_compareUnsignedAndJump):
3387 (JSC::JIT::emit_compareUnsigned):
3388 * llint/LowLevelInterpreter.asm:
3389 * llint/LowLevelInterpreter32_64.asm:
3390 * llint/LowLevelInterpreter64.asm:
3392 (JSC::ExpressionNode::isBinaryOpNode const):
3394 2017-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
3396 WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
3397 https://bugs.webkit.org/show_bug.cgi?id=178210
3399 Reviewed by Saam Barati.
3401 In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
3402 The former is an exported wasm function and the latter is an imported & exported function. Since they
3403 have [[Call]], they should be categorized into "function" in typeof operation.
3405 However, these functions do not implement our function protocol correctly. They inherit JSFunction.
3406 But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
3407 ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
3410 In this patch, we address the above issue by the following 2 fixes.
3412 1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
3413 InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
3414 implementation, we cannot make this JSFunctionType.
3416 2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
3417 changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
3418 classes of JSFunction (e.g. JSCustomGetterSetterFunction).
3420 * wasm/js/WebAssemblyFunction.h:
3421 (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
3422 (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
3423 (JSC::WebAssemblyFunction::callableFunction const): Deleted.
3424 (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
3425 (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
3426 * wasm/js/WebAssemblyWrapperFunction.cpp:
3427 (JSC::WebAssemblyWrapperFunction::createStructure):
3428 * wasm/js/WebAssemblyWrapperFunction.h:
3429 (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
3430 (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
3431 (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
3432 (JSC::WebAssemblyWrapperFunction::function): Deleted.
3434 2017-10-12 Per Arne Vollan <pvollan@apple.com>
3436 [Win64] JSC compile error.
3437 https://bugs.webkit.org/show_bug.cgi?id=178213
3439 Reviewed by Alex Christensen.
3441 Add static cast from int64 to uintptr_t.
3443 * dfg/DFGOSRExit.cpp:
3444 (JSC::DFG::OSRExit::executeOSRExit):
3446 2017-09-29 Filip Pizlo <fpizlo@apple.com>
3448 Enable gigacage on iOS
3449 https://bugs.webkit.org/show_bug.cgi?id=177586
3451 Reviewed by JF Bastien.
3453 The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
3454 executing JS, so the LLInt needs to know how to load from global variables on all platforms that
3455 have Gigacage. So, this teaches ARM64 how to load from global variables.
3457 Also, this makes the code handle disabling the gigacage a bit better.
3459 * ftl/FTLLowerDFGToB3.cpp:
3460 (JSC::FTL::DFG::LowerDFGToB3::caged):
3461 * jit/AssemblyHelpers.h:
3462 (JSC::AssemblyHelpers::cage):
3463 (JSC::AssemblyHelpers::cageConditionally):
3464 * offlineasm/arm64.rb:
3465 * offlineasm/asm.rb:
3466 * offlineasm/instructions.rb:
3468 2017-10-11 Sam Weinig <sam@webkit.org>
3470 Remove out-parameter variants of copyToVector
3471 https://bugs.webkit.org/show_bug.cgi?id=178155
3473 Reviewed by Tim Horton.
3475 * inspector/ScriptDebugServer.cpp:
3476 (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
3477 (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
3478 (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
3479 (Inspector::ScriptDebugServer::dispatchDidParseSource):
3480 (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
3481 (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
3483 Replace out-parameter based copyToVector, with one that returns a Vector.
3485 2017-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
3487 Support integrity="" on module scripts
3488 https://bugs.webkit.org/show_bug.cgi?id=177959
3490 Reviewed by Sam Weinig.
3492 This patch adds Subresource Integrity check for module scripts. Currently,
3493 only top-level module can be verified with integrity parameter since there
3494 is no way to perform integrity check onto the imported modules.
3496 In JSC side, we add `parameters` to the entry point of the module loader
3497 pipeline. This is fetching parameters and used when fetching modules.
3499 We separately pass this parameters to the pipeline along with the script fetcher.
3500 The script fetcher is only one for module graph since this is the initiator of
3501 this module graph loading. On the other hand, this parameters is for each
3502 module fetching. While setting "integrity" parameters to this script fetcher is
3503 sufficient to pass parameters to top-level-module's fetching, it is not enough
3504 for the future extension.
3506 In the future, we will investigate a way to pass parameters to each non-top-level
3507 module. At that time, this `parameters` should be per-module. This is because
3508 "integrity" value should be different for each module. For example, we will accept
3509 some form of syntax to add parameters to `import`. Some proposed syntax is like
3510 https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
3512 import "./xxx.js" integrity "xxxxxxx"
3514 In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
3515 `parameters` should be different from the one of top-level-module's one. That's why
3516 we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
3518 On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
3519 is important to offer module-graph-wide information. For example, import.meta would
3520 have `import.meta.scriptElement`, which is the script element fetching the module graph
3521 including this. So, we keep the both, script fetcher and parameters.
3522 https://github.com/tc39/proposal-import-meta
3524 This parameters will be finally used by pipeline's fetch hook, and WebCore side
3525 can use this parameters to fetch modules.
3527 We also further clean up the module pipeline by dropping unnecessary features.
3529 * JavaScriptCore.xcodeproj/project.pbxproj:
3531 * builtins/ModuleLoaderPrototype.js:
3533 (requestInstantiate):
3536 (loadAndEvaluateModule):
3537 This loadAndEvaluateModule should be implemented by just calling loadModule and
3538 linkAndEvaluateModule. We can drop requestReady and requestLink.
3540 (requestLink): Deleted.
3541 (requestImportModule): Deleted.
3543 (GlobalObject::moduleLoaderImportModule):
3544 (GlobalObject::moduleLoaderFetch):
3545 import and fetch hook takes parameters. Currently, we always pass `undefined` for
3546 import hook. When dynamic `import()` is extended to accept additional parameters
3547 like integrity, this parameters will be replaced with the actual value.
3549 (functionLoadModule):
3551 * runtime/Completion.cpp:
3552 (JSC::loadAndEvaluateModule):
3554 (JSC::importModule):
3555 * runtime/Completion.h:
3556 * runtime/JSGlobalObject.h:
3557 * runtime/JSGlobalObjectFunctions.cpp:
3558 (JSC::globalFuncImportModule):
3559 * runtime/JSModuleLoader.cpp:
3560 (JSC::JSModuleLoader::loadAndEvaluateModule):
3561 (JSC::JSModuleLoader::loadModule):
3562 (JSC::JSModuleLoader::requestImportModule):
3563 (JSC::JSModuleLoader::importModule):
3564 (JSC::JSModuleLoader::fetch):
3565 * runtime/JSModuleLoader.h:
3566 * runtime/JSScriptFetchParameters.cpp: Added.
3567 (JSC::JSScriptFetchParameters::destroy):
3568 * runtime/JSScriptFetchParameters.h: Added.
3569 (JSC::JSScriptFetchParameters::createStructure):
3570 (JSC::JSScriptFetchParameters::create):
3571 (JSC::JSScriptFetchParameters::parameters const):
3572 (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
3573 Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
3574 It is used in the module pipeline.
3577 * runtime/ModuleLoaderPrototype.cpp:
3578 (JSC::moduleLoaderPrototypeFetch):
3579 * runtime/ScriptFetchParameters.h: Added.
3580 (JSC::ScriptFetchParameters::~ScriptFetchParameters):
3581 Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
3582 by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
3589 2017-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
3591 import.meta should not be assignable
3592 https://bugs.webkit.org/show_bug.cgi?id=178202
3594 Reviewed by Saam Barati.
3596 `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
3597 and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
3598 We change the parser not to allow assignments for MetaPropertyNode.
3600 * bytecompiler/NodesCodegen.cpp:
3601 (JSC::ImportMetaNode::emitBytecode):
3602 * parser/ASTBuilder.h:
3603 (JSC::ASTBuilder::createImportMetaExpr):
3604 (JSC::ASTBuilder::isMetaProperty):
3605 (JSC::ASTBuilder::isImportMeta):
3606 * parser/NodeConstructors.h:
3607 (JSC::MetaPropertyNode::MetaPropertyNode):
3608 (JSC::NewTargetNode::NewTargetNode):
3609 (JSC::ImportMetaNode::ImportMetaNode):
3611 (JSC::ExpressionNode::isMetaProperty const):
3612 (JSC::ExpressionNode::isImportMeta const):
3613 * parser/Parser.cpp:
3614 (JSC::Parser<LexerType>::metaPropertyName):
3615 (JSC::Parser<LexerType>::parseAssignmentExpression):
3616 (JSC::Parser<LexerType>::parseMemberExpression):
3617 (JSC::Parser<LexerType>::parseUnaryExpression):
3619 * parser/SyntaxChecker.h:
3620 (JSC::SyntaxChecker::createImportMetaExpr):
3621 (JSC::SyntaxChecker::isMetaProperty):
3622 (JSC::SyntaxChecker::isImportMeta):
3624 2017-10-11 Saam Barati <sbarati@apple.com>
3626 Runtime disable poly proto because it may be a 3-4% Speedometer regression
3627 https://bugs.webkit.org/show_bug.cgi?id=178192
3629 Reviewed by JF Bastien.
3631 * runtime/Options.h:
3632 * runtime/StructureInlines.h:
3633 (JSC::Structure::shouldConvertToPolyProto):
3635 2017-10-11 Commit Queue <commit-queue@webkit.org>
3637 Unreviewed, rolling out r223113 and r223121.
3638 https://bugs.webkit.org/show_bug.cgi?id=178182
3640 Reintroduced 20% regression on Kraken (Requested by rniwa on
3643 Reverted changesets:
3645 "Enable gigacage on iOS"
3646 https://bugs.webkit.org/show_bug.cgi?id=177586
3647 https://trac.webkit.org/changeset/223113
3649 "Use one virtual allocation for all gigacages and their
3651 https://bugs.webkit.org/show_bug.cgi?id=178050
3652 https://trac.webkit.org/changeset/223121
3654 2017-10-11 Michael Saboff <msaboff@apple.com>
3656 Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
3657 https://bugs.webkit.org/show_bug.cgi?id=178106
3659 Reviewed by Keith Miller.
3661 * ucd/CaseFolding.txt:
3663 2017-10-11 Caio Lima <ticaiolima@gmail.com>
3665 Object properties are undefined in super.call() but not in this.call()
3666 https://bugs.webkit.org/show_bug.cgi?id=177230
3668 Reviewed by Saam Barati.
3670 Bytecode generation for "super.call(...)" or "super.apply(...)"
3671 shouldn't be considered as CallFunctionCallDotNode or
3672 ApplyFunctionCallDotNode because they should be considered as common
3673 super property access as any other function. According to spec[1],
3674 "super" is not refering to parent constructor.
3676 [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
3678 * parser/ASTBuilder.h:
3679 (JSC::ASTBuilder::makeFunctionCallNode):
3680 * parser/Parser.cpp:
3681 (JSC::Parser<LexerType>::parseMemberExpression):
3682 * parser/SyntaxChecker.h:
3683 (JSC::SyntaxChecker::makeFunctionCallNode):
3685 2017-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
3687 [JSC] Drop Instantiate hook in ES6 module loader
3688 https://bugs.webkit.org/show_bug.cgi?id=178162
3690 Reviewed by Sam Weinig.
3692 This patch is a part of patch series for module loader refactoring to adopt
3693 integrity="" parameters and introduce new whatwg module import mechanism.
3695 In this patch, we drop instantiate hook in module loader. This hook is originally
3696 introduced because it is defined in whatwg/loader spec. But this hook is not
3697 used in our implementation, and this hook won't be used since (1) whatwg/loader
3698 spec is abandoned, and (2) this type of hooks should be done in Service Workers.
3700 In addition, this patch applies some cleaning up of our module loader JS code
3701 to simplify things. This change paves the way to more efficient loader implementation
3702 with great flexibility to adopt integrity="" parameters.
3704 * builtins/ModuleLoaderPrototype.js:
3705 (requestInstantiate):
3707 provide is changed to provideFetch since we only used this function with Fetch stage parameter.
3709 (fulfillInstantiate): Deleted.
3710 (commitInstantiated): Deleted.
3711 (instantiation): Deleted.
3712 They are merged into requestInstantiate code. This is simpler.
3716 * runtime/Completion.cpp:
3717 (JSC::loadAndEvaluateModule):
3719 * runtime/JSGlobalObject.cpp:
3720 * runtime/JSGlobalObject.h:
3721 * runtime/JSModuleLoader.cpp:
3722 (JSC::JSModuleLoader::provideFetch):
3723 (JSC::JSModuleLoader::provide): Deleted.
3724 Changed to provideFetch.
3726 (JSC::JSModuleLoader::instantiate): Deleted.
3729 * runtime/JSModuleLoader.h:
3730 * runtime/ModuleLoaderPrototype.cpp:
3731 (JSC::moduleLoaderPrototypeInstantiate): Deleted.
3734 2017-10-10 Saam Barati <sbarati@apple.com>
3736 Prototype structure transition should be a deferred transition
3737 https://bugs.webkit.org/show_bug.cgi?id=177734
3739 Reviewed by Keith Miller.
3741 Absence ObjectPropertyConditions work by verifying both that the Structure
3742 does not have a particular property and that its prototype has
3743 remained constant. However, the prototype transition was firing
3744 the transition watchpoint before setting the object's structure.
3745 This meant that isValid for Absence would never return false because
3746 the prototype changed. Clearly this is wrong. The reason this didn't
3747 break OPCs in general is that we'd also check if we could still watch
3748 the OPC. In this case, we can't still watch it because we're inspecting
3749 a structure with an invalidated transition watchpoint. To fix
3750 this weird quirk of the code, I'm making it so that doing a prototype
3751 transition uses the DeferredStructureTransitionWatchpointFire machinery.
3753 This patch also fixes some dead code that I left in regarding
3756 * bytecode/PropertyCondition.cpp:
3757 (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
3758 * runtime/JSObject.cpp:
3759 (JSC::JSObject::setPrototypeDirect):
3760 * runtime/Structure.cpp:
3761 (JSC::Structure::changePrototypeTransition):
3762 * runtime/Structure.h:
3764 2017-10-10 Robin Morisset <rmorisset@apple.com>
3766 Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
3767 https://bugs.webkit.org/show_bug.cgi?id=177926
3769 Reviewed by Saam Barati.
3771 When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
3772 With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
3773 The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
3775 * dfg/DFGByteCodeParser.cpp:
3776 (JSC::DFG::ByteCodeParser::inlineCall):
3777 (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3778 (JSC::DFG::ByteCodeParser::handleInlining):
3779 (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
3780 (JSC::DFG::ByteCodeParser::parse):
3782 2017-10-10 Guillaume Emont <guijemont@igalia.com>
3784 Fix compilation when MASM_PROBE (and therefore DFG) are disabled
3785 https://bugs.webkit.org/show_bug.cgi?id=178134
3787 Reviewed by Saam Barati.
3789 * bytecode/CodeBlock.cpp:
3790 * bytecode/CodeBlock.h:
3791 Disable some code when building without DFG_JIT.
3793 2017-10-10 Sam Weinig <sam@webkit.org>
3795 Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
3796 https://bugs.webkit.org/show_bug.cgi?id=178102
3798 Reviewed by Tim Horton.
3800 * inspector/agents/InspectorDebuggerAgent.cpp:
3801 (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
3803 2017-10-10 Michael Saboff <msaboff@apple.com>
3805 Unreviewed build fix.
3807 Removed unused lambda capture.
3809 * yarr/YarrPattern.cpp:
3810 (JSC::Yarr::CharacterClassConstructor::appendInverted):
3812 2017-10-10 Saam Barati <sbarati@apple.com>
3814 The prototype cache should be aware of the Executable it generates a Structure for
3815 https://bugs.webkit.org/show_bug.cgi?id=177907
3817 Reviewed by Filip Pizlo.
3819 This patch renames PrototypeMap to StructureCache because
3820 it is no longer a map of the prototypes in the VM. It's
3821 only used to cache Structures during object construction.
3823 The main change of this patch is to guarantee that Structures generated
3824 by the create_this originating from different two different Executables'
3825 bytecode won't hash-cons to the same thing. Previously, we could hash-cons
3826 them depending on the JSObject* prototype pointer. This would cause the last
3827 thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
3828 happened because when we initialize a JSFunction's ObjectAllocationProfile,
3829 we set the resulting Structure's poly proto watchpoint. This could cause a Structure
3830 generating from some Executable e1 to end up with the poly proto watchpoint
3831 for another Executable e2 simply because JSFunctions backed by e1 and e2
3832 shared the same prototype. Then, based on profiling information, we may fire the
3833 wrong Executable's poly proto watchpoint. This patch fixes this bug by
3834 guaranteeing that Structures generating from create_this for different
3835 Executables are unique even if they share the same prototype by adding
3836 the FunctionExecutable* as another field in PrototypeKey.
3838 * JavaScriptCore.xcodeproj/project.pbxproj:
3840 * bytecode/InternalFunctionAllocationProfile.h:
3841 (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
3842 * bytecode/ObjectAllocationProfile.cpp:
3843 (JSC::ObjectAllocationProfile::initializeProfile):
3844 * dfg/DFGOperations.cpp:
3845 * runtime/CommonSlowPaths.cpp:
3846 (JSC::SLOW_PATH_DECL):
3847 * runtime/InternalFunction.cpp:
3848 (JSC::InternalFunction::createSubclassStructureSlow):
3849 * runtime/IteratorOperations.cpp:
3850 (JSC::createIteratorResultObjectStructure):
3851 * runtime/JSBoundFunction.cpp:
3852 (JSC::getBoundFunctionStructure):
3853 * runtime/JSGlobalObject.cpp:
3854 (JSC::JSGlobalObject::init):
3855 * runtime/ObjectConstructor.h:
3856 (JSC::constructEmptyObject):
3857 * runtime/PrototypeKey.h:
3858 (JSC::PrototypeKey::PrototypeKey):
3859 (JSC::PrototypeKey::executable const):
3860 (JSC::PrototypeKey::operator== const):
3861 (JSC::PrototypeKey::hash const):
3862 * runtime/PrototypeMap.cpp: Removed.
3863 * runtime/PrototypeMap.h: Removed.
3864 * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
3865 (JSC::StructureCache::createEmptyStructure):
3866 (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
3867 (JSC::StructureCache::emptyObjectStructureForPrototype):
3868 (JSC::PrototypeMap::createEmptyStructure): Deleted.
3869 (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
3870 (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
3871 * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
3872 (JSC::StructureCache::StructureCache):
3873 (JSC::PrototypeMap::PrototypeMap): Deleted.
3878 2017-10-09 Yusuke Suzuki <utatane.tea@gmail.com>
3880 `async` should be able to be used as an imported binding name
3881 https://bugs.webkit.org/show_bug.cgi?id=176573
3883 Reviewed by Saam Barati.
3885 Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
3886 and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
3887 since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
3888 For example, import declaration failed to bind imported binding to the name "async" because