1 2017-11-07 Mark Lam <mark.lam@apple.com>
3 AccessCase::generateImpl() should exclude the result register when restoring registers after a call.
4 https://bugs.webkit.org/show_bug.cgi?id=179355
5 <rdar://problem/35263053>
7 Reviewed by Saam Barati.
9 In the Transition case in AccessCase::generateImpl(), we were restoring registers
10 using restoreLiveRegistersFromStackForCall() without excluding the scratchGPR
11 where we previously stashed the reallocated butterfly. If the generated code is
12 under heavy register pressure, scratchGPR could have been from the set of preserved
13 registers, and hence, would be restored by restoreLiveRegistersFromStackForCall().
14 As a result, the restoration would trash the butterfly result we stored there.
15 This patch fixes the issue by excluding the scratchGPR in the restoration.
17 * bytecode/AccessCase.cpp:
18 (JSC::AccessCase::generateImpl):
20 2017-11-06 Robin Morisset <rmorisset@apple.com>
22 CodeBlock::usesOpcode() is dead code
23 https://bugs.webkit.org/show_bug.cgi?id=179316
25 Reviewed by Yusuke Suzuki.
27 Remove CodeBlock::usesOpcode which is dead code
29 * bytecode/CodeBlock.cpp:
30 * bytecode/CodeBlock.h:
32 2017-11-05 Yusuke Suzuki <utatane.tea@gmail.com>
34 JIT call inline caches should cache calls to objects with getCallData/getConstructData traps
35 https://bugs.webkit.org/show_bug.cgi?id=144458
37 Reviewed by Saam Barati.
39 Previously only JSFunction is handled by CallLinkInfo's caching mechanism. This means that
40 InternalFunction calls are not cached and they always go to the slow path. This is not good because
42 1. We need to query getCallData/getConstructData every time in the slow path.
43 2. CallLinkInfo tells nothing in the higher tier JITs.
45 This patch starts handling InternalFunction in CallLinkInfo's caching mechanism. We change InternalFunction
46 to hold pointers to the functions for call and construct. We have new stubs that can call/construct
47 InternalFunction. And we return this code pointer as a result of setup call to use CallLinkInfo mechanism.
49 This patch is critical to optimizing derived Array construction[1] since it starts using CallLinkInfo
50 for InternalFunction. Previously we did not record any information to CallLinkInfo. Except for the
51 case that DFGByteCodeParser figures out InternalFunction constant, we cannot attempt to emit DFG
52 nodes for these InternalFunctions since CallLinkInfo tells us nothing.
54 Attached microbenchmarks show performance improvement.
58 dfg-internal-function-construct 1.6439+-0.0826 ^ 1.2829+-0.0727 ^ definitely 1.2813x faster
59 dfg-internal-function-not-handled-construct 2.1862+-0.1361 2.0696+-0.1201 might be 1.0564x faster
60 dfg-internal-function-not-handled-call 20.7592+-0.9085 19.7369+-0.7921 might be 1.0518x faster
61 dfg-internal-function-call 1.6856+-0.0967 ^ 1.2771+-0.0744 ^ definitely 1.3198x faster
63 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
65 * API/JSCallbackFunction.cpp:
66 (JSC::JSCallbackFunction::JSCallbackFunction):
67 (JSC::JSCallbackFunction::getCallData): Deleted.
68 * API/JSCallbackFunction.h:
69 (JSC::JSCallbackFunction::createStructure):
70 * API/ObjCCallbackFunction.h:
71 (JSC::ObjCCallbackFunction::createStructure):
72 * API/ObjCCallbackFunction.mm:
73 (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
74 (JSC::ObjCCallbackFunction::getCallData): Deleted.
75 (JSC::ObjCCallbackFunction::getConstructData): Deleted.
76 * bytecode/BytecodeDumper.cpp:
77 (JSC::BytecodeDumper<Block>::printCallOp):
78 * bytecode/BytecodeList.json:
79 * bytecode/CallLinkInfo.cpp:
80 (JSC::CallLinkInfo::setCallee):
81 (JSC::CallLinkInfo::callee):
82 (JSC::CallLinkInfo::setLastSeenCallee):
83 (JSC::CallLinkInfo::lastSeenCallee):
84 (JSC::CallLinkInfo::visitWeak):
85 * bytecode/CallLinkInfo.h:
86 * bytecode/CallLinkStatus.cpp:
87 (JSC::CallLinkStatus::computeFromCallLinkInfo):
88 * bytecode/LLIntCallLinkInfo.h:
89 * jit/JITOperations.cpp:
91 (JSC::JITThunks::ctiInternalFunctionCall):
92 (JSC::JITThunks::ctiInternalFunctionConstruct):
96 (JSC::linkPolymorphicCall):
98 * jit/ThunkGenerators.cpp:
99 (JSC::virtualThunkFor):
100 (JSC::nativeForGenerator):
101 (JSC::nativeCallGenerator):
102 (JSC::nativeTailCallGenerator):
103 (JSC::nativeTailCallWithoutSavedTagsGenerator):
104 (JSC::nativeConstructGenerator):
105 (JSC::internalFunctionCallGenerator):
106 (JSC::internalFunctionConstructGenerator):
107 * jit/ThunkGenerators.h:
108 * llint/LLIntSlowPaths.cpp:
109 (JSC::LLInt::setUpCall):
110 * llint/LowLevelInterpreter.asm:
111 * llint/LowLevelInterpreter32_64.asm:
112 * llint/LowLevelInterpreter64.asm:
113 * runtime/ArrayConstructor.cpp:
114 (JSC::ArrayConstructor::ArrayConstructor):
115 (JSC::ArrayConstructor::getConstructData): Deleted.
116 (JSC::ArrayConstructor::getCallData): Deleted.
117 * runtime/ArrayConstructor.h:
118 (JSC::ArrayConstructor::createStructure):
119 * runtime/AsyncFunctionConstructor.cpp:
120 (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
121 (JSC::AsyncFunctionConstructor::finishCreation):
122 (JSC::AsyncFunctionConstructor::getCallData): Deleted.
123 (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
124 * runtime/AsyncFunctionConstructor.h:
125 (JSC::AsyncFunctionConstructor::createStructure):
126 * runtime/AsyncGeneratorFunctionConstructor.cpp:
127 (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor):
128 (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
129 (JSC::AsyncGeneratorFunctionConstructor::getCallData): Deleted.
130 (JSC::AsyncGeneratorFunctionConstructor::getConstructData): Deleted.
131 * runtime/AsyncGeneratorFunctionConstructor.h:
132 (JSC::AsyncGeneratorFunctionConstructor::createStructure):
133 * runtime/BooleanConstructor.cpp:
134 (JSC::callBooleanConstructor):
135 (JSC::BooleanConstructor::BooleanConstructor):
136 (JSC::BooleanConstructor::finishCreation):
137 (JSC::BooleanConstructor::getConstructData): Deleted.
138 (JSC::BooleanConstructor::getCallData): Deleted.
139 * runtime/BooleanConstructor.h:
140 (JSC::BooleanConstructor::createStructure):
141 * runtime/DateConstructor.cpp:
142 (JSC::DateConstructor::DateConstructor):
143 (JSC::DateConstructor::getConstructData): Deleted.
144 (JSC::DateConstructor::getCallData): Deleted.
145 * runtime/DateConstructor.h:
146 (JSC::DateConstructor::createStructure):
148 (JSC::StrictModeTypeErrorFunction::StrictModeTypeErrorFunction):
149 (JSC::StrictModeTypeErrorFunction::createStructure):
150 (JSC::StrictModeTypeErrorFunction::getConstructData): Deleted.
151 (JSC::StrictModeTypeErrorFunction::getCallData): Deleted.
152 * runtime/ErrorConstructor.cpp:
153 (JSC::ErrorConstructor::ErrorConstructor):
154 (JSC::ErrorConstructor::getConstructData): Deleted.
155 (JSC::ErrorConstructor::getCallData): Deleted.
156 * runtime/ErrorConstructor.h:
157 (JSC::ErrorConstructor::createStructure):
158 * runtime/FunctionConstructor.cpp:
159 (JSC::FunctionConstructor::FunctionConstructor):
160 (JSC::FunctionConstructor::finishCreation):
161 (JSC::FunctionConstructor::getConstructData): Deleted.
162 (JSC::FunctionConstructor::getCallData): Deleted.
163 * runtime/FunctionConstructor.h:
164 (JSC::FunctionConstructor::createStructure):
165 * runtime/FunctionPrototype.cpp:
166 (JSC::callFunctionPrototype):
167 (JSC::FunctionPrototype::FunctionPrototype):
168 (JSC::FunctionPrototype::getCallData): Deleted.
169 * runtime/FunctionPrototype.h:
170 (JSC::FunctionPrototype::createStructure):
171 * runtime/GeneratorFunctionConstructor.cpp:
172 (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
173 (JSC::GeneratorFunctionConstructor::finishCreation):
174 (JSC::GeneratorFunctionConstructor::getCallData): Deleted.
175 (JSC::GeneratorFunctionConstructor::getConstructData): Deleted.
176 * runtime/GeneratorFunctionConstructor.h:
177 (JSC::GeneratorFunctionConstructor::createStructure):
178 * runtime/InternalFunction.cpp:
179 (JSC::InternalFunction::InternalFunction):
180 (JSC::InternalFunction::finishCreation):
181 (JSC::InternalFunction::getCallData):
182 (JSC::InternalFunction::getConstructData):
183 * runtime/InternalFunction.h:
184 (JSC::InternalFunction::createStructure):
185 (JSC::InternalFunction::nativeFunctionFor):
186 (JSC::InternalFunction::offsetOfNativeFunctionFor):
187 * runtime/IntlCollatorConstructor.cpp:
188 (JSC::IntlCollatorConstructor::createStructure):
189 (JSC::IntlCollatorConstructor::IntlCollatorConstructor):
190 (JSC::IntlCollatorConstructor::getConstructData): Deleted.
191 (JSC::IntlCollatorConstructor::getCallData): Deleted.
192 * runtime/IntlCollatorConstructor.h:
193 * runtime/IntlDateTimeFormatConstructor.cpp:
194 (JSC::IntlDateTimeFormatConstructor::createStructure):
195 (JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor):
196 (JSC::IntlDateTimeFormatConstructor::getConstructData): Deleted.
197 (JSC::IntlDateTimeFormatConstructor::getCallData): Deleted.
198 * runtime/IntlDateTimeFormatConstructor.h:
199 * runtime/IntlNumberFormatConstructor.cpp:
200 (JSC::IntlNumberFormatConstructor::createStructure):
201 (JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor):
202 (JSC::IntlNumberFormatConstructor::getConstructData): Deleted.
203 (JSC::IntlNumberFormatConstructor::getCallData): Deleted.
204 * runtime/IntlNumberFormatConstructor.h:
205 * runtime/JSArrayBufferConstructor.cpp:
206 (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
207 (JSC::JSArrayBufferConstructor::createStructure):
208 (JSC::JSArrayBufferConstructor::getConstructData): Deleted.
209 (JSC::JSArrayBufferConstructor::getCallData): Deleted.
210 * runtime/JSArrayBufferConstructor.h:
211 * runtime/JSGenericTypedArrayViewConstructor.h:
212 * runtime/JSGenericTypedArrayViewConstructorInlines.h:
213 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::JSGenericTypedArrayViewConstructor):
214 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::createStructure):
215 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getConstructData): Deleted.
216 (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData): Deleted.
217 * runtime/JSInternalPromiseConstructor.cpp:
218 (JSC::JSInternalPromiseConstructor::createStructure):
219 (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
220 (JSC::JSInternalPromiseConstructor::getConstructData): Deleted.
221 (JSC::JSInternalPromiseConstructor::getCallData): Deleted.
222 * runtime/JSInternalPromiseConstructor.h:
223 * runtime/JSPromiseConstructor.cpp:
224 (JSC::JSPromiseConstructor::createStructure):
225 (JSC::JSPromiseConstructor::JSPromiseConstructor):
226 (JSC::JSPromiseConstructor::getConstructData): Deleted.
227 (JSC::JSPromiseConstructor::getCallData): Deleted.
228 * runtime/JSPromiseConstructor.h:
230 * runtime/JSTypedArrayViewConstructor.cpp:
231 (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
232 (JSC::JSTypedArrayViewConstructor::createStructure):
233 (JSC::JSTypedArrayViewConstructor::getConstructData): Deleted.
234 (JSC::JSTypedArrayViewConstructor::getCallData): Deleted.
235 * runtime/JSTypedArrayViewConstructor.h:
236 * runtime/MapConstructor.cpp:
237 (JSC::MapConstructor::MapConstructor):
238 (JSC::MapConstructor::getConstructData): Deleted.
239 (JSC::MapConstructor::getCallData): Deleted.
240 * runtime/MapConstructor.h:
241 (JSC::MapConstructor::createStructure):
242 (JSC::MapConstructor::MapConstructor): Deleted.
243 * runtime/NativeErrorConstructor.cpp:
244 (JSC::NativeErrorConstructor::NativeErrorConstructor):
245 (JSC::NativeErrorConstructor::getConstructData): Deleted.
246 (JSC::NativeErrorConstructor::getCallData): Deleted.
247 * runtime/NativeErrorConstructor.h:
248 (JSC::NativeErrorConstructor::createStructure):
249 * runtime/NullGetterFunction.cpp:
250 (JSC::NullGetterFunction::NullGetterFunction):
251 (JSC::NullGetterFunction::getCallData): Deleted.
252 (JSC::NullGetterFunction::getConstructData): Deleted.
253 * runtime/NullGetterFunction.h:
254 (JSC::NullGetterFunction::createStructure):
255 (JSC::NullGetterFunction::NullGetterFunction): Deleted.
256 * runtime/NullSetterFunction.cpp:
257 (JSC::NullSetterFunction::NullSetterFunction):
258 (JSC::NullSetterFunction::getCallData): Deleted.
259 (JSC::NullSetterFunction::getConstructData): Deleted.
260 * runtime/NullSetterFunction.h:
261 (JSC::NullSetterFunction::createStructure):
262 (JSC::NullSetterFunction::NullSetterFunction): Deleted.
263 * runtime/NumberConstructor.cpp:
264 (JSC::NumberConstructor::NumberConstructor):
265 (JSC::constructNumberConstructor):
266 (JSC::constructWithNumberConstructor): Deleted.
267 (JSC::NumberConstructor::getConstructData): Deleted.
268 (JSC::NumberConstructor::getCallData): Deleted.
269 * runtime/NumberConstructor.h:
270 (JSC::NumberConstructor::createStructure):
271 * runtime/ObjectConstructor.cpp:
272 (JSC::ObjectConstructor::ObjectConstructor):
273 (JSC::ObjectConstructor::getConstructData): Deleted.
274 (JSC::ObjectConstructor::getCallData): Deleted.
275 * runtime/ObjectConstructor.h:
276 (JSC::ObjectConstructor::createStructure):
277 * runtime/ProxyConstructor.cpp:
278 (JSC::ProxyConstructor::ProxyConstructor):
279 (JSC::ProxyConstructor::getConstructData): Deleted.
280 (JSC::ProxyConstructor::getCallData): Deleted.
281 * runtime/ProxyConstructor.h:
282 (JSC::ProxyConstructor::createStructure):
283 * runtime/ProxyRevoke.cpp:
284 (JSC::ProxyRevoke::ProxyRevoke):
285 (JSC::ProxyRevoke::getCallData): Deleted.
286 * runtime/ProxyRevoke.h:
287 (JSC::ProxyRevoke::createStructure):
288 * runtime/RegExpConstructor.cpp:
289 (JSC::RegExpConstructor::RegExpConstructor):
290 (JSC::RegExpConstructor::getConstructData): Deleted.
291 (JSC::RegExpConstructor::getCallData): Deleted.
292 * runtime/RegExpConstructor.h:
293 (JSC::RegExpConstructor::createStructure):
294 * runtime/SetConstructor.cpp:
295 (JSC::SetConstructor::SetConstructor):
296 (JSC::SetConstructor::getConstructData): Deleted.
297 (JSC::SetConstructor::getCallData): Deleted.
298 * runtime/SetConstructor.h:
299 (JSC::SetConstructor::createStructure):
300 (JSC::SetConstructor::SetConstructor): Deleted.
301 * runtime/StringConstructor.cpp:
302 (JSC::StringConstructor::StringConstructor):
303 (JSC::StringConstructor::getConstructData): Deleted.
304 (JSC::StringConstructor::getCallData): Deleted.
305 * runtime/StringConstructor.h:
306 (JSC::StringConstructor::createStructure):
307 * runtime/SymbolConstructor.cpp:
308 (JSC::SymbolConstructor::SymbolConstructor):
309 (JSC::SymbolConstructor::getConstructData): Deleted.
310 (JSC::SymbolConstructor::getCallData): Deleted.
311 * runtime/SymbolConstructor.h:
312 (JSC::SymbolConstructor::createStructure):
315 (JSC::VM::getCTIInternalFunctionTrampolineFor):
317 * runtime/WeakMapConstructor.cpp:
318 (JSC::WeakMapConstructor::WeakMapConstructor):
319 (JSC::WeakMapConstructor::getConstructData): Deleted.
320 (JSC::WeakMapConstructor::getCallData): Deleted.
321 * runtime/WeakMapConstructor.h:
322 (JSC::WeakMapConstructor::createStructure):
323 (JSC::WeakMapConstructor::WeakMapConstructor): Deleted.
324 * runtime/WeakSetConstructor.cpp:
325 (JSC::WeakSetConstructor::WeakSetConstructor):
326 (JSC::WeakSetConstructor::getConstructData): Deleted.
327 (JSC::WeakSetConstructor::getCallData): Deleted.
328 * runtime/WeakSetConstructor.h:
329 (JSC::WeakSetConstructor::createStructure):
330 (JSC::WeakSetConstructor::WeakSetConstructor): Deleted.
331 * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
332 (JSC::WebAssemblyCompileErrorConstructor::createStructure):
333 (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
334 (JSC::WebAssemblyCompileErrorConstructor::getConstructData): Deleted.
335 (JSC::WebAssemblyCompileErrorConstructor::getCallData): Deleted.
336 * wasm/js/WebAssemblyCompileErrorConstructor.h:
337 * wasm/js/WebAssemblyInstanceConstructor.cpp:
338 (JSC::WebAssemblyInstanceConstructor::createStructure):
339 (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
340 (JSC::WebAssemblyInstanceConstructor::getConstructData): Deleted.
341 (JSC::WebAssemblyInstanceConstructor::getCallData): Deleted.
342 * wasm/js/WebAssemblyInstanceConstructor.h:
343 * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
344 (JSC::WebAssemblyLinkErrorConstructor::createStructure):
345 (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
346 (JSC::WebAssemblyLinkErrorConstructor::getConstructData): Deleted.
347 (JSC::WebAssemblyLinkErrorConstructor::getCallData): Deleted.
348 * wasm/js/WebAssemblyLinkErrorConstructor.h:
349 * wasm/js/WebAssemblyMemoryConstructor.cpp:
350 (JSC::WebAssemblyMemoryConstructor::createStructure):
351 (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
352 (JSC::WebAssemblyMemoryConstructor::getConstructData): Deleted.
353 (JSC::WebAssemblyMemoryConstructor::getCallData): Deleted.
354 * wasm/js/WebAssemblyMemoryConstructor.h:
355 * wasm/js/WebAssemblyModuleConstructor.cpp:
356 (JSC::WebAssemblyModuleConstructor::createStructure):
357 (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
358 (JSC::WebAssemblyModuleConstructor::getConstructData): Deleted.
359 (JSC::WebAssemblyModuleConstructor::getCallData): Deleted.
360 * wasm/js/WebAssemblyModuleConstructor.h:
361 * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
362 (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
363 (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
364 (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData): Deleted.
365 (JSC::WebAssemblyRuntimeErrorConstructor::getCallData): Deleted.
366 * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
367 * wasm/js/WebAssemblyTableConstructor.cpp:
368 (JSC::WebAssemblyTableConstructor::createStructure):
369 (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
370 (JSC::WebAssemblyTableConstructor::getConstructData): Deleted.
371 (JSC::WebAssemblyTableConstructor::getCallData): Deleted.
372 * wasm/js/WebAssemblyTableConstructor.h:
374 2017-11-03 Michael Saboff <msaboff@apple.com>
376 The Abstract Interpreter needs to change similar to clobberize() in r224366
377 https://bugs.webkit.org/show_bug.cgi?id=179267
379 Reviewed by Saam Barati.
381 Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
382 cases in the abstract interpreter to match what was done for r224366.
384 * dfg/DFGAbstractInterpreterInlines.h:
385 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
387 2017-11-03 Keith Miller <keith_miller@apple.com>
389 PutProperytSlot should inform the IC about the property before effects.
390 https://bugs.webkit.org/show_bug.cgi?id=179262
392 Reviewed by Mark Lam.
394 This patch fixes an issue where we choose to cache setters based on
395 incorrect information. If we did so we might end up OSR exiting
396 more than we would otherwise need to. The new model is that the
397 PutPropertySlot should inform the IC of what the property looked
398 like before any potential side effects might have occurred.
400 * runtime/JSObject.cpp:
401 (JSC::JSObject::putInlineSlow):
405 2017-11-03 Mark Lam <mark.lam@apple.com>
407 CachedCall (and its clients) needs overflow checks.
408 https://bugs.webkit.org/show_bug.cgi?id=179185
410 Reviewed by JF Bastien.
412 * interpreter/CachedCall.h:
413 (JSC::CachedCall::CachedCall):
414 (JSC::CachedCall::hasOverflowedArguments):
416 (JSC::MarkedArgumentBuffer::clear):
417 * runtime/StringPrototype.cpp:
418 (JSC::replaceUsingRegExpSearch):
420 2017-11-03 Devin Rousso <webkit@devinrousso.com>
422 Web Inspector: Canvas2D Profiling: highlight expensive context commands in the captured command log
423 https://bugs.webkit.org/show_bug.cgi?id=178302
424 <rdar://problem/33158849>
426 Reviewed by Brian Burg.
428 * inspector/protocol/Recording.json:
429 Add `duration` to each Frame that represents the total time of all the recorded actions.
431 2017-11-02 Devin Rousso <webkit@devinrousso.com>
433 Web Inspector: Canvas Tab: show supported GL extensions for selected canvas
434 https://bugs.webkit.org/show_bug.cgi?id=179070
435 <rdar://problem/35278276>
437 Reviewed by Brian Burg.
439 * inspector/protocol/Canvas.json:
440 Add `extensionEnabled` event that is fired each time `getExtension` is called with a
441 different string on a WebGL context.
443 2017-11-02 Joseph Pecoraro <pecoraro@apple.com>
445 Make ServiceWorker a Remote Inspector debuggable target
446 https://bugs.webkit.org/show_bug.cgi?id=179043
447 <rdar://problem/34126008>
449 Reviewed by Brian Burg.
451 * inspector/remote/RemoteControllableTarget.h:
452 * inspector/remote/RemoteInspectionTarget.h:
453 * inspector/remote/RemoteInspectorConstants.h:
454 Include a new ServiceWorker remote inspector target type.
456 * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
457 (Inspector::RemoteInspector::listingForInspectionTarget const):
458 Implement listing for a ServiceWorker to include a URL like a page.
460 * inspector/remote/glib/RemoteInspectorGlib.cpp:
461 (Inspector::RemoteInspector::listingForInspectionTarget const):
462 Bail for ServiceWorker support in glib. They will need to implement their support.
464 2017-11-02 Michael Saboff <msaboff@apple.com>
466 DFG needs to handle code motion of code in for..in loop bodies
467 https://bugs.webkit.org/show_bug.cgi?id=179212
469 Reviewed by Keith Miller.
471 The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
472 make calls with side effects. Updated clobberize() for those nodes to take that into account.
474 * dfg/DFGClobberize.h:
475 (JSC::DFG::clobberize):
477 2017-11-02 Joseph Pecoraro <pecoraro@apple.com>
479 Inspector should display service worker served responses properly
480 https://bugs.webkit.org/show_bug.cgi?id=178597
481 <rdar://problem/35186111>
483 Reviewed by Brian Burg.
485 * inspector/protocol/Network.json:
486 Expose a new "service-worker" response source.
488 2017-11-02 Filip Pizlo <fpizlo@apple.com>
490 AI does not correctly model the clobber case of ArithClz32
491 https://bugs.webkit.org/show_bug.cgi?id=179188
493 Reviewed by Michael Saboff.
495 The non-Int32 case clobbers the world because it may call valueOf.
497 * dfg/DFGAbstractInterpreterInlines.h:
498 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
500 2017-11-02 Yusuke Suzuki <utatane.tea@gmail.com>
502 Unreviewed, release throw scope
503 https://bugs.webkit.org/show_bug.cgi?id=178726
505 * dfg/DFGOperations.cpp:
507 2017-11-02 Frederic Wang <fwang@igalia.com>
509 Add references to bug 179167 in FIXME comments
510 https://bugs.webkit.org/show_bug.cgi?id=179168
512 Reviewed by Daniel Bates.
514 * Configurations/FeatureDefines.xcconfig:
516 2017-11-01 Jeremy Jones <jeremyj@apple.com>
518 Implement WKFullscreenWindowController for iOS.
519 https://bugs.webkit.org/show_bug.cgi?id=178924
520 rdar://problem/34697120
522 Reviewed by Simon Fraser.
524 Enable ENABLE_FULLSCREEN_API for iOS.
526 * Configurations/FeatureDefines.xcconfig:
528 2017-11-01 Mark Lam <mark.lam@apple.com>
530 Add support to throw OOM if MarkedArgumentBuffer may overflow.
531 https://bugs.webkit.org/show_bug.cgi?id=179092
532 <rdar://problem/35116160>
534 Reviewed by Saam Barati.
536 The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long
537 time, which renders it unsuitable for automated tests. Instead, I've run a
538 test manually to verify that an OutOfMemoryError will be thrown when an overflow
541 The MarkedArgumentBuffer's destructor will now assert that the client has indeed
542 checked for an overflow after invoking methods that may result in an overflow i.e.
543 the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called.
544 This is only done on debug builds.
546 * API/JSObjectRef.cpp:
547 (JSObjectMakeFunction):
550 (JSObjectMakeRegExp):
551 (JSObjectCallAsFunction):
552 (JSObjectCallAsConstructor):
553 * dfg/DFGOperations.cpp:
554 * inspector/InjectedScriptManager.cpp:
555 (Inspector::InjectedScriptManager::createInjectedScript):
556 * inspector/JSJavaScriptCallFrame.cpp:
557 (Inspector::JSJavaScriptCallFrame::scopeChain const):
558 * interpreter/Interpreter.cpp:
559 (JSC::Interpreter::executeProgram):
561 (functionDollarAgentReceiveBroadcast):
562 * runtime/ArgList.cpp:
563 (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
564 (JSC::MarkedArgumentBuffer::expandCapacity):
565 (JSC::MarkedArgumentBuffer::slowAppend):
567 (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
568 (JSC::MarkedArgumentBuffer::appendWithAction):
569 (JSC::MarkedArgumentBuffer::append):
570 (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow):
571 (JSC::MarkedArgumentBuffer::hasOverflowed):
572 (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck):
573 (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck):
574 * runtime/ArrayPrototype.cpp:
575 * runtime/CommonSlowPaths.cpp:
576 (JSC::SLOW_PATH_DECL):
577 * runtime/GetterSetter.cpp:
579 * runtime/IteratorOperations.cpp:
581 (JSC::iteratorClose):
582 * runtime/JSBoundFunction.cpp:
583 (JSC::boundThisNoArgsFunctionCall):
584 (JSC::boundFunctionCall):
585 (JSC::boundThisNoArgsFunctionConstruct):
586 (JSC::boundFunctionConstruct):
587 * runtime/JSGenericTypedArrayViewConstructorInlines.h:
588 (JSC::constructGenericTypedArrayViewFromIterator):
589 * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
590 (JSC::genericTypedArrayViewProtoFuncSlice):
591 (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
592 * runtime/JSGlobalObject.cpp:
593 (JSC::JSGlobalObject::haveABadTime):
594 * runtime/JSInternalPromise.cpp:
595 (JSC::JSInternalPromise::then):
597 (JSC::JSJobMicrotask::run):
598 * runtime/JSMapIterator.cpp:
599 (JSC::JSMapIterator::createPair):
600 * runtime/JSModuleLoader.cpp:
601 (JSC::JSModuleLoader::provideFetch):
602 (JSC::JSModuleLoader::loadAndEvaluateModule):
603 (JSC::JSModuleLoader::loadModule):
604 (JSC::JSModuleLoader::linkAndEvaluateModule):
605 (JSC::JSModuleLoader::requestImportModule):
606 * runtime/JSONObject.cpp:
607 (JSC::Stringifier::toJSONImpl):
608 (JSC::Stringifier::appendStringifiedValue):
609 (JSC::Walker::callReviver):
610 * runtime/JSObject.cpp:
611 (JSC::ordinarySetSlow):
612 (JSC::callToPrimitiveFunction):
613 (JSC::JSObject::hasInstance):
614 * runtime/JSPromise.cpp:
615 (JSC::JSPromise::initialize):
616 (JSC::JSPromise::resolve):
617 * runtime/JSPromiseDeferred.cpp:
618 (JSC::newPromiseCapability):
620 * runtime/JSSetIterator.cpp:
621 (JSC::JSSetIterator::createPair):
622 * runtime/LiteralParser.cpp:
623 (JSC::LiteralParser<CharType>::parse):
624 * runtime/MapConstructor.cpp:
626 * runtime/ObjectConstructor.cpp:
627 (JSC::defineProperties):
628 * runtime/ProxyObject.cpp:
629 (JSC::performProxyGet):
630 (JSC::ProxyObject::performInternalMethodGetOwnProperty):
631 (JSC::ProxyObject::performHasProperty):
632 (JSC::ProxyObject::performPut):
633 (JSC::performProxyCall):
634 (JSC::performProxyConstruct):
635 (JSC::ProxyObject::performDelete):
636 (JSC::ProxyObject::performPreventExtensions):
637 (JSC::ProxyObject::performIsExtensible):
638 (JSC::ProxyObject::performDefineOwnProperty):
639 (JSC::ProxyObject::performGetOwnPropertyNames):
640 (JSC::ProxyObject::performSetPrototype):
641 (JSC::ProxyObject::performGetPrototype):
642 * runtime/ReflectObject.cpp:
643 (JSC::reflectObjectConstruct):
644 * runtime/SetConstructor.cpp:
646 * runtime/StringPrototype.cpp:
647 (JSC::replaceUsingRegExpSearch):
648 (JSC::replaceUsingStringSearch):
649 * runtime/WeakMapConstructor.cpp:
650 (JSC::constructWeakMap):
651 * runtime/WeakSetConstructor.cpp:
652 (JSC::constructWeakSet):
653 * wasm/js/WasmToJS.cpp:
654 (JSC::Wasm::wasmToJS):
656 2017-11-01 Michael Saboff <msaboff@apple.com>
658 Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
659 https://bugs.webkit.org/show_bug.cgi?id=179140
661 Reviewed by Saam Barati.
663 Added overflow checks to computation of arg count plus this.
665 * dfg/DFGSpeculativeJIT32_64.cpp:
666 (JSC::DFG::SpeculativeJIT::compile):
667 * dfg/DFGSpeculativeJIT64.cpp:
668 (JSC::DFG::SpeculativeJIT::compile):
669 * ftl/FTLLowerDFGToB3.cpp:
670 (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
672 2017-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
674 Unreviewed, use weakPointer instead of FTLOutput::weakPointer
675 https://bugs.webkit.org/show_bug.cgi?id=178934
677 * ftl/FTLLowerDFGToB3.cpp:
678 (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
680 2017-11-01 Yusuke Suzuki <utatane.tea@gmail.com>
682 [JSC] Introduce @toObject
683 https://bugs.webkit.org/show_bug.cgi?id=178726
685 Reviewed by Saam Barati.
687 This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node.
688 Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject
689 is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls
690 ObjectConstructor in LLInt and Baseline.
692 We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to
693 offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation
695 if (this === @undefined || this === null)
696 @throwTypeError("error message");
697 var object = @Object(this);
701 var object = @toObject(this, "error message");
703 And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined,
704 ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world.
705 In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect.
707 It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one.
709 * builtins/ArrayConstructor.js:
711 * builtins/ArrayPrototype.js:
727 (globalPrivate.concatSlowPath):
729 * builtins/DatePrototype.js:
730 (toLocaleString.toDateTimeOptionsAnyAll):
732 (toLocaleDateString.toDateTimeOptionsDateDate):
733 (toLocaleDateString):
734 (toLocaleTimeString.toDateTimeOptionsTimeTime):
735 (toLocaleTimeString):
736 * builtins/GlobalOperations.js:
737 (globalPrivate.copyDataProperties):
738 (globalPrivate.copyDataPropertiesNoExclusions):
739 * builtins/ObjectConstructor.js:
741 * builtins/StringConstructor.js:
743 * builtins/TypedArrayConstructor.js:
745 * builtins/TypedArrayPrototype.js:
748 * bytecode/BytecodeDumper.cpp:
749 (JSC::BytecodeDumper<Block>::dumpBytecode):
750 * bytecode/BytecodeIntrinsicRegistry.h:
751 * bytecode/BytecodeList.json:
752 * bytecode/BytecodeUseDef.h:
753 (JSC::computeUsesForBytecodeOffset):
754 (JSC::computeDefsForBytecodeOffset):
755 * bytecode/CodeBlock.cpp:
756 (JSC::CodeBlock::finishCreation):
757 * bytecompiler/BytecodeGenerator.cpp:
758 (JSC::BytecodeGenerator::emitToObject):
759 * bytecompiler/BytecodeGenerator.h:
760 * bytecompiler/NodesCodegen.cpp:
761 (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject):
762 * dfg/DFGAbstractInterpreterInlines.h:
763 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
764 * dfg/DFGByteCodeParser.cpp:
765 (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
766 (JSC::DFG::ByteCodeParser::parseBlock):
767 * dfg/DFGCapabilities.cpp:
768 (JSC::DFG::capabilityLevel):
769 * dfg/DFGClobberize.h:
770 (JSC::DFG::clobberize):
773 * dfg/DFGFixupPhase.cpp:
774 (JSC::DFG::FixupPhase::fixupNode):
775 (JSC::DFG::FixupPhase::fixupToObject):
776 (JSC::DFG::FixupPhase::fixupCallObjectConstructor):
778 (JSC::DFG::Node::convertToCallObjectConstructor):
779 (JSC::DFG::Node::convertToNewStringObject):
780 (JSC::DFG::Node::convertToNewObject):
781 (JSC::DFG::Node::hasIdentifier):
782 (JSC::DFG::Node::hasHeapPrediction):
783 (JSC::DFG::Node::hasCellOperand):
785 * dfg/DFGOperations.cpp:
786 * dfg/DFGOperations.h:
787 * dfg/DFGPredictionPropagationPhase.cpp:
788 * dfg/DFGSafeToExecute.h:
789 (JSC::DFG::safeToExecute):
790 * dfg/DFGSpeculativeJIT.cpp:
791 (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor):
792 (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
793 * dfg/DFGSpeculativeJIT.h:
794 (JSC::DFG::SpeculativeJIT::callOperation):
795 * dfg/DFGSpeculativeJIT32_64.cpp:
796 (JSC::DFG::SpeculativeJIT::compile):
797 * dfg/DFGSpeculativeJIT64.cpp:
798 (JSC::DFG::SpeculativeJIT::compile):
799 * ftl/FTLCapabilities.cpp:
800 (JSC::FTL::canCompile):
801 * ftl/FTLLowerDFGToB3.cpp:
802 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
803 (JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor):
804 (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
806 (JSC::JIT::privateCompileMainPass):
807 (JSC::JIT::privateCompileSlowCases):
809 * jit/JITOpcodes.cpp:
810 (JSC::JIT::emit_op_to_object):
811 (JSC::JIT::emitSlow_op_to_object):
812 * jit/JITOpcodes32_64.cpp:
813 (JSC::JIT::emit_op_to_object):
814 (JSC::JIT::emitSlow_op_to_object):
815 * jit/JITOperations.cpp:
816 * jit/JITOperations.h:
817 * llint/LowLevelInterpreter32_64.asm:
818 * llint/LowLevelInterpreter64.asm:
819 * runtime/CommonSlowPaths.cpp:
820 (JSC::SLOW_PATH_DECL):
821 * runtime/CommonSlowPaths.h:
823 2017-11-01 Fujii Hironori <Hironori.Fujii@sony.com>
825 Use LazyNeverDestroyed instead of DEFINE_GLOBAL
826 https://bugs.webkit.org/show_bug.cgi?id=174979
828 Reviewed by Yusuke Suzuki.
830 * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC.
832 2017-10-27 Yusuke Suzuki <utatane.tea@gmail.com>
834 [DFG][FTL] Introduce StringSlice
835 https://bugs.webkit.org/show_bug.cgi?id=178934
837 Reviewed by Saam Barati.
839 String.prototype.slice is one of the most frequently called function in ARES-6/Babylon.
840 This patch introduces StringSlice DFG node to optimize it in DFG and FTL.
842 This patch's StringSlice node optimizes the following things.
844 1. Empty string generation is accelerated. It is fully executed inline.
845 2. One char string generation is accelerated. `< 0x100` character is supported right now.
846 It is the same to charAt acceleration.
847 3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized
850 We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL.
851 And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change
852 in subsequent changes.
854 This patch improves ARES-6/Babylon performance by 3% in steady state.
857 Running... Babylon ( 1 to go)
858 firstIteration: 50.05 +- 13.68 ms
859 averageWorstCase: 16.80 +- 1.27 ms
860 steadyState: 7.53 +- 0.22 ms
863 Running... Babylon ( 1 to go)
864 firstIteration: 50.91 +- 13.41 ms
865 averageWorstCase: 16.12 +- 0.99 ms
866 steadyState: 7.30 +- 0.29 ms
868 * dfg/DFGAbstractInterpreterInlines.h:
869 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
870 * dfg/DFGBackwardsPropagationPhase.cpp:
871 (JSC::DFG::BackwardsPropagationPhase::propagate):
872 * dfg/DFGByteCodeParser.cpp:
873 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
874 * dfg/DFGClobberize.h:
875 (JSC::DFG::clobberize):
878 * dfg/DFGFixupPhase.cpp:
879 (JSC::DFG::FixupPhase::fixupNode):
881 * dfg/DFGOperations.cpp:
882 * dfg/DFGOperations.h:
883 * dfg/DFGPredictionPropagationPhase.cpp:
884 * dfg/DFGSafeToExecute.h:
885 (JSC::DFG::safeToExecute):
886 * dfg/DFGSpeculativeJIT.cpp:
887 (JSC::DFG::SpeculativeJIT::compileStringSlice):
888 (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
889 (JSC::DFG::SpeculativeJIT::compileArraySlice):
890 (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
891 * dfg/DFGSpeculativeJIT.h:
892 (JSC::DFG::SpeculativeJIT::callOperation):
893 * dfg/DFGSpeculativeJIT32_64.cpp:
894 (JSC::DFG::SpeculativeJIT::compile):
895 * dfg/DFGSpeculativeJIT64.cpp:
896 (JSC::DFG::SpeculativeJIT::compile):
897 * ftl/FTLCapabilities.cpp:
898 (JSC::FTL::canCompile):
899 * ftl/FTLLowerDFGToB3.cpp:
900 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
901 (JSC::FTL::DFG::LowerDFGToB3::populateSliceRange):
902 (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
903 (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
904 * jit/JITOperations.h:
905 * runtime/Intrinsic.cpp:
906 (JSC::intrinsicName):
907 * runtime/Intrinsic.h:
908 * runtime/StringPrototype.cpp:
909 (JSC::StringPrototype::finishCreation):
911 2017-10-31 JF Bastien <jfbastien@apple.com>
913 WebAssembly: Wasm::IndexOrName has a raw pointer to Name
914 https://bugs.webkit.org/show_bug.cgi?id=176644
916 Reviewed by Michael Saboff.
918 IndexOrName now keeps a RefPtr to its original NameSection, which
919 holds the Name (or references nullptr if Index). Holding onto the
920 entire section seems like the better thing to do, since backtraces
921 probably contain multiple names from the same Module.
923 * JavaScriptCore.xcodeproj/project.pbxproj:
924 * interpreter/Interpreter.cpp:
925 (JSC::GetStackTraceFunctor::operator() const):
926 * interpreter/StackVisitor.h: Frame is no longer POD because of the
928 * runtime/StackFrame.cpp:
929 (JSC::StackFrame::StackFrame):
930 * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
931 (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
932 (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
933 * wasm/WasmBBQPlanInlines.h:
934 (JSC::Wasm::BBQPlan::initializeCallees):
935 * wasm/WasmCallee.cpp:
936 (JSC::Wasm::Callee::Callee):
938 (JSC::Wasm::Callee::create):
939 * wasm/WasmFormat.h: Move NameSection to its own header.
940 (JSC::Wasm::isValidNameType):
941 (JSC::Wasm::NameSection::get): Deleted.
942 * wasm/WasmIndexOrName.cpp:
943 (JSC::Wasm::IndexOrName::IndexOrName):
944 (JSC::Wasm::makeString):
945 * wasm/WasmIndexOrName.h:
946 (JSC::Wasm::IndexOrName::IndexOrName):
947 (JSC::Wasm::IndexOrName::isEmpty const):
948 (JSC::Wasm::IndexOrName::isIndex const):
949 * wasm/WasmModuleInformation.cpp:
950 (JSC::Wasm::ModuleInformation::ModuleInformation):
951 * wasm/WasmModuleInformation.h:
952 (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
953 * wasm/WasmNameSection.h:
954 (JSC::Wasm::NameSection::get):
955 (JSC::Wasm::NameSection::create): Deleted.
956 * wasm/WasmNameSectionParser.cpp:
957 (JSC::Wasm::NameSectionParser::parse):
958 * wasm/WasmNameSectionParser.h:
959 * wasm/WasmOMGPlan.cpp:
960 (JSC::Wasm::OMGPlan::work):
962 2017-10-31 Tim Horton <timothy_horton@apple.com>
964 Clean up some drag and drop feature flags
965 https://bugs.webkit.org/show_bug.cgi?id=179082
967 Reviewed by Simon Fraser.
969 * Configurations/FeatureDefines.xcconfig:
971 2017-10-31 Commit Queue <commit-queue@webkit.org>
973 Unreviewed, rolling out r224243, r224246, and r224248.
974 https://bugs.webkit.org/show_bug.cgi?id=179083
976 The patch and fix broke the Windows build. (Requested by
977 mlewis13 on #webkit).
981 "StructureStubInfo should have GPRReg members not int8_ts"
982 https://bugs.webkit.org/show_bug.cgi?id=179071
983 https://trac.webkit.org/changeset/224243
985 "Make all register enums be backed by uint8_t."
986 https://bugs.webkit.org/show_bug.cgi?id=179074
987 https://trac.webkit.org/changeset/224246
989 "Unreviewed, windows build fix."
990 https://trac.webkit.org/changeset/224248
992 2017-10-31 Tim Horton <timothy_horton@apple.com>
994 Fix up some content filtering feature flags
995 https://bugs.webkit.org/show_bug.cgi?id=179079
997 Reviewed by Simon Fraser.
999 * Configurations/FeatureDefines.xcconfig:
1001 2017-10-31 Keith Miller <keith_miller@apple.com>
1003 Unreviewed, windows build fix.
1005 * assembler/X86Assembler.h:
1006 (JSC::X86Assembler::numberOfRegisters):
1007 (JSC::X86Assembler::numberOfSPRegisters):
1008 (JSC::X86Assembler::numberOfFPRegisters):
1010 2017-10-31 Keith Miller <keith_miller@apple.com>
1012 Make all register enums be backed by uint8_t.
1013 https://bugs.webkit.org/show_bug.cgi?id=179074
1015 Reviewed by Mark Lam.
1017 * assembler/ARM64Assembler.h:
1018 * assembler/ARMAssembler.h:
1019 * assembler/ARMv7Assembler.h:
1020 * assembler/MIPSAssembler.h:
1021 * assembler/MacroAssembler.h:
1022 * assembler/X86Assembler.h:
1024 2017-10-31 Keith Miller <keith_miller@apple.com>
1026 StructureStubInfo should have GPRReg members not int8_ts
1027 https://bugs.webkit.org/show_bug.cgi?id=179071
1029 Reviewed by Michael Saboff.
1031 This patch makes the various RegisterID enums be backed by
1032 uint8_t. This means that we can remove the old int8_t members in
1033 StructureStubInfo and replace them with the correct enum types.
1035 Also, this fixes an indentation issue in ARMv7Assembler.h.
1037 * assembler/ARM64Assembler.h:
1038 * assembler/ARMAssembler.h:
1039 * assembler/ARMv7Assembler.h:
1040 (JSC::ARMRegisters::asSingle):
1041 (JSC::ARMRegisters::asDouble):
1042 * assembler/MIPSAssembler.h:
1043 * assembler/X86Assembler.h:
1044 * bytecode/InlineAccess.cpp:
1045 (JSC::InlineAccess::generateSelfPropertyAccess):
1046 (JSC::getScratchRegister):
1047 * bytecode/PolymorphicAccess.cpp:
1048 (JSC::PolymorphicAccess::regenerate):
1049 * bytecode/StructureStubInfo.h:
1050 (JSC::StructureStubInfo::valueRegs const):
1051 * dfg/DFGSpeculativeJIT.cpp:
1052 (JSC::DFG::SpeculativeJIT::compileIn):
1053 * ftl/FTLLowerDFGToB3.cpp:
1054 (JSC::FTL::DFG::LowerDFGToB3::compileIn):
1055 * jit/JITInlineCacheGenerator.cpp:
1056 (JSC::JITByIdGenerator::JITByIdGenerator):
1057 (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
1059 2017-10-31 Devin Rousso <webkit@devinrousso.com>
1061 Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
1062 https://bugs.webkit.org/show_bug.cgi?id=179048
1064 Reviewed by Mark Lam.
1066 * inspector/ScriptCallStackFactory.h:
1067 * inspector/ScriptCallStackFactory.cpp:
1068 (createScriptCallStack):
1069 (createScriptCallStackForConsole):
1070 (createScriptCallStackFromException):
1072 * inspector/ConsoleMessage.cpp:
1073 (Inspector::ConsoleMessage::autogenerateMetadata):
1074 * inspector/JSGlobalObjectInspectorController.cpp:
1075 (Inspector::JSGlobalObjectInspectorController::reportAPIException):
1076 * inspector/agents/InspectorConsoleAgent.cpp:
1077 (Inspector::InspectorConsoleAgent::count):
1078 * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
1079 (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
1081 2017-10-31 Carlos Garcia Campos <cgarcia@igalia.com>
1083 Unreviewed. Fix GTK+ make distcheck.
1085 Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.
1089 2017-10-30 Saam Barati <sbarati@apple.com>
1091 We need a storeStoreFence before storing to the instruction stream's live variable catch data
1092 https://bugs.webkit.org/show_bug.cgi?id=178649
1094 Reviewed by Keith Miller.
1096 * bytecode/CodeBlock.cpp:
1097 (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
1099 2017-10-30 Michael Catanzaro <mcatanzaro@igalia.com>
1101 [WPE] Fix build warnings
1102 https://bugs.webkit.org/show_bug.cgi?id=178899
1104 Reviewed by Carlos Alberto Lopez Perez.
1106 * PlatformWPE.cmake:
1108 2017-10-30 Zan Dobersek <zdobersek@igalia.com>
1110 [ARMv7] Fix initial start register support in YarrJIT
1111 https://bugs.webkit.org/show_bug.cgi?id=178641
1113 Reviewed by Saam Barati.
1115 * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
1116 YarrGenerator class. r6 should be avoided since it's already used inside
1117 MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
1118 can be used as the frame pointer register when targetting ARM Thumb2.
1120 2017-10-30 Zan Dobersek <zdobersek@igalia.com>
1122 [ARM64][Linux] Re-enable Gigacage
1123 https://bugs.webkit.org/show_bug.cgi?id=178130
1125 Reviewed by Michael Catanzaro.
1127 Guard the current globaladdr opcode implementation for ARM64 with
1128 OS(DARWIN) as it's only usable for Mach-O.
1130 For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
1131 have to be used. The .loh directive can't be used as it's not supported
1132 in GCC or the ld linker.
1134 On every other OS target, a compilation error is thrown.
1136 * offlineasm/arm64.rb:
1138 2017-10-27 Devin Rousso <webkit@devinrousso.com>
1140 Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
1141 https://bugs.webkit.org/show_bug.cgi?id=178799
1142 <rdar://problem/35175805>
1144 Reviewed by Brian Burg.
1146 * inspector/protocol/Canvas.json:
1147 Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.
1149 2017-10-27 Yusuke Suzuki <utatane.tea@gmail.com>
1151 [JSC] Tweak ES6 generator function to allow inlining
1152 https://bugs.webkit.org/show_bug.cgi?id=178935
1154 Reviewed by Saam Barati.
1156 We optimize builtins' generator helper functions to allow them inlined in the caller side.
1157 This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
1158 them inlined in DFG.
1162 spread-generator.es6 301.2637+-11.1011 ^ 260.5905+-14.2258 ^ definitely 1.1561x faster
1163 generator.es6 269.6030+-13.2435 ^ 148.8840+-6.7614 ^ definitely 1.8108x faster
1165 * builtins/GeneratorPrototype.js:
1166 (globalPrivate.generatorResume):
1171 2017-10-27 Saam Barati <sbarati@apple.com>
1173 Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
1174 https://bugs.webkit.org/show_bug.cgi?id=178949
1176 Reviewed by Keith Miller.
1178 This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
1179 so that we don't need to recompute liveness for the same UnlinkedCodeBlock
1180 more than once. To do this, this patch solidifies the invariant that CodeBlock
1181 linking can't do anything that would change the result of liveness. For example,
1182 it can't introduce new locals. This invariant was met my JSC before, because we
1183 didn't do anything in bytecode linking that would change liveness. However, it is
1184 now a correctness requirement that we don't do anything that would change the
1185 result of running liveness. To support this change, I've refactored BytecodeGraph
1186 to not be tied to a CodeBlockType*. Things that perform liveness will pass in
1187 CodeBlockType* and the instruction stream as needed. This means that we may
1188 compute liveness with one CodeBlock*'s instruction stream, and then perform
1189 queries on that analysis with a different CodeBlock*'s instruction stream.
1191 This seems to be a 2% JSBench progression.
1193 * bytecode/BytecodeGeneratorification.cpp:
1194 (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
1195 (JSC::BytecodeGeneratorification::graph):
1196 (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
1197 (JSC::GeneratorLivenessAnalysis::run):
1198 (JSC::BytecodeGeneratorification::run):
1199 * bytecode/BytecodeGraph.h:
1200 (JSC::BytecodeGraph::BytecodeGraph):
1201 (JSC::BytecodeGraph::codeBlock const): Deleted.
1202 (JSC::BytecodeGraph::instructions): Deleted.
1203 (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
1204 * bytecode/BytecodeLivenessAnalysis.cpp:
1205 (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
1206 (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
1207 (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
1208 (JSC::BytecodeLivenessAnalysis::computeKills):
1209 (JSC::BytecodeLivenessAnalysis::dumpResults):
1210 (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
1211 (JSC::BytecodeLivenessAnalysis::compute): Deleted.
1212 * bytecode/BytecodeLivenessAnalysis.h:
1213 * bytecode/BytecodeLivenessAnalysisInlines.h:
1214 (JSC::BytecodeLivenessPropagation::stepOverInstruction):
1215 (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
1216 (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
1217 (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
1218 (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
1219 * bytecode/BytecodeRewriter.cpp:
1220 (JSC::BytecodeRewriter::applyModification):
1221 (JSC::BytecodeRewriter::execute):
1222 (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
1223 * bytecode/BytecodeRewriter.h:
1224 (JSC::BytecodeRewriter::BytecodeRewriter):
1225 (JSC::BytecodeRewriter::removeBytecode):
1226 (JSC::BytecodeRewriter::graph):
1227 * bytecode/CodeBlock.cpp:
1228 (JSC::CodeBlock::finishCreation):
1229 (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
1230 (JSC::CodeBlock::validate):
1231 (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
1232 * bytecode/CodeBlock.h:
1233 (JSC::CodeBlock::livenessAnalysis):
1234 * bytecode/UnlinkedCodeBlock.cpp:
1235 (JSC::UnlinkedCodeBlock::applyModification):
1236 (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
1237 * bytecode/UnlinkedCodeBlock.h:
1238 (JSC::UnlinkedCodeBlock::livenessAnalysis):
1240 (JSC::DFG::Graph::livenessFor):
1241 (JSC::DFG::Graph::killsFor):
1243 (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
1245 (JSC::JIT::privateCompileMainPass):
1247 2017-10-27 Keith Miller <keith_miller@apple.com>
1249 Add unified source list files and build scripts to Xcode project navigator
1250 https://bugs.webkit.org/show_bug.cgi?id=178959
1252 Reviewed by Andy Estes.
1254 Also, Add some extra source files for so new .cpp/.mm files don't cause the build
1255 to fail right away. We already do this in WebCore.
1257 * JavaScriptCore.xcodeproj/project.pbxproj:
1258 * PlatformMac.cmake:
1259 * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.
1261 2017-10-27 JF Bastien <jfbastien@apple.com>
1263 WebAssembly: update arbitrary limits to what browsers use
1264 https://bugs.webkit.org/show_bug.cgi?id=178946
1265 <rdar://problem/34257412>
1266 <rdar://problem/34501154>
1268 Reviewed by Saam Barati.
1270 https://github.com/WebAssembly/design/issues/1138 discusses the
1271 arbitrary function size limit, which it turns out Chrome and
1272 Firefox didn't enforce. We didn't use it because it was
1273 ridiculously low and actual programs ran into that limit (bummer
1274 for Edge which just shipped it...). Now that we agree on a high
1275 arbitrary program limit, let's update it! While I'm doing this
1276 there are a few other spots that I polished to use Checked or
1277 better check limits overall.
1279 * wasm/WasmB3IRGenerator.cpp:
1280 (JSC::Wasm::B3IRGenerator::addLocal):
1281 * wasm/WasmFormat.cpp:
1282 (JSC::Wasm::Segment::create):
1283 * wasm/WasmFunctionParser.h:
1284 (JSC::Wasm::FunctionParser<Context>::parse):
1285 * wasm/WasmInstance.cpp:
1286 * wasm/WasmLimits.h:
1287 * wasm/WasmModuleParser.cpp:
1288 (JSC::Wasm::ModuleParser::parseGlobal):
1289 (JSC::Wasm::ModuleParser::parseCode):
1290 (JSC::Wasm::ModuleParser::parseData):
1291 * wasm/WasmSignature.h:
1292 (JSC::Wasm::Signature::allocatedSize):
1293 * wasm/WasmTable.cpp:
1294 (JSC::Wasm::Table::Table):
1295 * wasm/js/JSWebAssemblyTable.cpp:
1296 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1297 (JSC::JSWebAssemblyTable::grow):
1299 2017-10-26 Michael Saboff <msaboff@apple.com>
1301 REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
1302 https://bugs.webkit.org/show_bug.cgi?id=178890
1304 Reviewed by Keith Miller.
1306 We need to let a contained subpattern backtrack before declaring that the containing
1307 parenthesis doesn't match. If the subpattern fails to match backtracking, then we
1308 can check to see if we trying to backtrack below the minimum match count.
1310 * yarr/YarrInterpreter.cpp:
1311 (JSC::Yarr::Interpreter::backtrackParentheses):
1313 2017-10-26 Mark Lam <mark.lam@apple.com>
1315 JSRopeString::RopeBuilder::append() should check for overflows.
1316 https://bugs.webkit.org/show_bug.cgi?id=178385
1317 <rdar://problem/35027468>
1319 Reviewed by Saam Barati.
1321 1. Made RopeString check for overflow like the Checked class does.
1322 2. Added a missing overflow check in objectProtoFuncToString().
1324 * runtime/JSString.cpp:
1325 (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
1326 (JSC::JSRopeString::RopeBuilder::expand): Deleted.
1327 * runtime/JSString.h:
1328 * runtime/ObjectPrototype.cpp:
1329 (JSC::objectProtoFuncToString):
1330 * runtime/Operations.h:
1331 (JSC::jsStringFromRegisterArray):
1332 (JSC::jsStringFromArguments):
1334 2017-10-26 JF Bastien <jfbastien@apple.com>
1336 WebAssembly: no VM / JS version of our implementation
1337 https://bugs.webkit.org/show_bug.cgi?id=177472
1339 Reviewed by Michael Saboff.
1341 This patch removes all appearances of "JS" and "VM" in the wasm
1342 directory. These now only appear in the wasm/js directory, which
1343 is only used in a JS embedding of wasm. It should therefore now be
1344 possible to create non-JS embeddings of wasm through JSC, though
1345 it'll still require:
1347 - Mild codegen for wasm<->embedder calls;
1348 - A strategy for trap handling (no need for full unwind! Could kill).
1349 - Creation of the Wasm::* objects.
1350 - Calling convention handling to call the embedder.
1351 - Handling of multiple embedders (see #177475, this is optional).
1353 Most of the patch consists in renaming JSWebAssemblyInstance to
1354 Instance, and removing temporary copies which I'd added to make
1355 this specific patch very simple.
1357 * interpreter/CallFrame.cpp:
1358 (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
1359 which needs to know about who "owns" the Wasm::Instance. In a JS
1360 embedding it's the JSWebAssemblyInstance.
1361 * wasm/WasmB3IRGenerator.cpp:
1362 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1363 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1364 (JSC::Wasm::B3IRGenerator::addGrowMemory):
1365 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1366 (JSC::Wasm::B3IRGenerator::getGlobal):
1367 (JSC::Wasm::B3IRGenerator::setGlobal):
1368 (JSC::Wasm::B3IRGenerator::addCall):
1369 (JSC::Wasm::B3IRGenerator::addCallIndirect):
1370 * wasm/WasmBinding.cpp:
1371 (JSC::Wasm::wasmToWasm):
1372 * wasm/WasmContext.cpp:
1373 (JSC::Wasm::Context::load const):
1374 (JSC::Wasm::Context::store):
1375 * wasm/WasmContext.h:
1376 * wasm/WasmEmbedder.h:
1377 * wasm/WasmInstance.cpp:
1378 (JSC::Wasm::Instance::Instance):
1379 (JSC::Wasm::Instance::create):
1380 (JSC::Wasm::Instance::extraMemoryAllocated const):
1381 * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
1382 "tail" import information from JSWebAssemblyInstance over to here.
1383 (JSC::Wasm::Instance::finalizeCreation):
1384 (JSC::Wasm::Instance::owner const):
1385 (JSC::Wasm::Instance::offsetOfOwner):
1386 (JSC::Wasm::Instance::context const):
1387 (JSC::Wasm::Instance::setMemory):
1388 (JSC::Wasm::Instance::setTable):
1389 (JSC::Wasm::Instance::offsetOfMemory):
1390 (JSC::Wasm::Instance::offsetOfGlobals):
1391 (JSC::Wasm::Instance::offsetOfTable):
1392 (JSC::Wasm::Instance::offsetOfTail):
1393 (JSC::Wasm::Instance::numImportFunctions const):
1394 (JSC::Wasm::Instance::importFunctionInfo):
1395 (JSC::Wasm::Instance::offsetOfTargetInstance):
1396 (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
1397 (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
1398 (JSC::Wasm::Instance::offsetOfImportFunction):
1399 (JSC::Wasm::Instance::importFunction):
1400 (JSC::Wasm::Instance::allocationSize):
1401 (JSC::Wasm::Instance::create): Deleted.
1402 * wasm/WasmOMGPlan.cpp:
1403 (JSC::Wasm::OMGPlan::runForIndex):
1404 * wasm/WasmOMGPlan.h:
1405 * wasm/WasmTable.cpp:
1406 (JSC::Wasm::Table::Table):
1407 (JSC::Wasm::Table::setFunction):
1409 * wasm/WasmThunks.cpp:
1410 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1411 (JSC::Wasm::triggerOMGTierUpThunkGenerator):
1412 * wasm/js/JSToWasm.cpp:
1413 (JSC::Wasm::createJSToWasmWrapper):
1414 * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
1415 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
1416 decides what the import function is. Here we must properly
1417 placement-new it to what we've elected (and initialize it later).
1418 (JSC::JSWebAssemblyInstance::visitChildren):
1419 (JSC::JSWebAssemblyInstance::finalizeCreation):
1420 (JSC::JSWebAssemblyInstance::create):
1421 * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
1422 (JSC::JSWebAssemblyInstance::instance):
1423 (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
1424 (JSC::JSWebAssemblyInstance::setMemory):
1425 (JSC::JSWebAssemblyInstance::table):
1426 (JSC::JSWebAssemblyInstance::setTable):
1427 (JSC::JSWebAssemblyInstance::offsetOfInstance):
1428 (JSC::JSWebAssemblyInstance::offsetOfCallee):
1429 (JSC::JSWebAssemblyInstance::context const): Deleted.
1430 (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
1432 (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
1433 (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
1434 (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
1435 (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
1436 (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
1437 (JSC::JSWebAssemblyInstance::importFunction): Deleted.
1438 (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
1439 (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
1440 (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
1441 (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
1442 (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
1443 (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
1444 (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
1445 (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
1446 (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
1447 (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
1448 (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
1449 (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
1450 (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
1451 (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
1452 * wasm/js/JSWebAssemblyTable.cpp:
1453 (JSC::JSWebAssemblyTable::setFunction):
1454 * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
1455 (JSC::Wasm::materializeImportJSCell):
1456 (JSC::Wasm::handleBadI64Use):
1457 (JSC::Wasm::wasmToJS):
1458 (JSC::Wasm::wasmToJSException):
1459 * wasm/js/WasmToJS.h:
1460 * wasm/js/WebAssemblyFunction.cpp:
1461 (JSC::callWebAssemblyFunction):
1462 * wasm/js/WebAssemblyInstanceConstructor.cpp:
1463 (JSC::constructJSWebAssemblyInstance):
1464 * wasm/js/WebAssemblyModuleRecord.cpp:
1465 (JSC::WebAssemblyModuleRecord::link):
1466 (JSC::WebAssemblyModuleRecord::evaluate):
1467 * wasm/js/WebAssemblyPrototype.cpp:
1469 * wasm/js/WebAssemblyWrapperFunction.cpp:
1470 (JSC::WebAssemblyWrapperFunction::create):
1472 2017-10-25 Devin Rousso <webkit@devinrousso.com>
1474 Web Inspector: provide a way to enable/disable event listeners
1475 https://bugs.webkit.org/show_bug.cgi?id=177451
1476 <rdar://problem/34994925>
1478 Reviewed by Joseph Pecoraro.
1480 * inspector/protocol/DOM.json:
1481 Add `setEventListenerDisabled` command that enables/disables a specific event listener
1482 during event dispatch. When a disabled event listener is fired, the listener's callback will
1485 2017-10-25 Commit Queue <commit-queue@webkit.org>
1487 Unreviewed, rolling out r223691 and r223729.
1488 https://bugs.webkit.org/show_bug.cgi?id=178834
1490 Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
1491 by rniwa on #webkit).
1493 Reverted changesets:
1495 "Turn recursive tail calls into loops"
1496 https://bugs.webkit.org/show_bug.cgi?id=176601
1497 https://trac.webkit.org/changeset/223691
1499 "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
1500 comparison is always false due to limited range of data type
1502 https://bugs.webkit.org/show_bug.cgi?id=178543
1503 https://trac.webkit.org/changeset/223729
1505 2017-10-25 Michael Saboff <msaboff@apple.com>
1507 REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
1508 https://bugs.webkit.org/show_bug.cgi?id=178825
1510 Reviewed by Mark Lam.
1512 Enable ARC for ARM64_32. This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
1514 * Configurations/ToolExecutable.xcconfig:
1516 2017-10-25 Keith Miller <keith_miller@apple.com>
1518 Fix implicit cast of enum, which seems to break the windows build of unified sources.
1519 https://bugs.webkit.org/show_bug.cgi?id=178822
1521 Reviewed by Saam Barati.
1523 * bytecode/DFGExitProfile.h:
1524 (JSC::DFG::FrequentExitSite::hash const):
1526 2017-10-24 Michael Saboff <msaboff@apple.com>
1528 Allow OjbC Weak References when building TestAPI
1529 https://bugs.webkit.org/show_bug.cgi?id=178748
1531 Reviewed by Dan Bernstein.
1533 Set TestAPI build flag Weak References in Manual Retain Release to true.
1535 * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
1536 * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
1538 2017-10-24 Eric Carlson <eric.carlson@apple.com>
1540 Web Inspector: Enable WebKit logging configuration and display
1541 https://bugs.webkit.org/show_bug.cgi?id=177027
1542 <rdar://problem/33964767>
1544 Reviewed by Joseph Pecoraro.
1546 * inspector/ConsoleMessage.cpp:
1547 (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage ->
1548 Inspector::Protocol::Console::ChannelSource.
1549 * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
1550 (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
1551 specific to a JSContext yet, so return an empty channel array.
1552 (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
1553 * inspector/agents/JSGlobalObjectConsoleAgent.h:
1555 * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
1556 and setLoggingChannelLevel.
1558 * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
1559 * inspector/scripts/tests/generic/expected/enum-values.json-result:
1560 * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1561 * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1562 * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1563 * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1565 * runtime/ConsoleTypes.h: Add Media and WebRTC.
1567 2017-10-24 Michael Saboff <msaboff@apple.com>
1569 Allow OjbC Weak References when building TestAPI
1570 https://bugs.webkit.org/show_bug.cgi?id=178748
1572 Reviewed by Saam Barati.
1574 Set TestAPI build flag Weak References in Manual Retain Release to true.
1576 * JavaScriptCore.xcodeproj/project.pbxproj:
1578 2017-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
1580 [FTL] Support NewStringObject
1581 https://bugs.webkit.org/show_bug.cgi?id=178737
1583 Reviewed by Saam Barati.
1585 FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
1586 After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
1588 * ftl/FTLAbstractHeapRepository.h:
1589 * ftl/FTLCapabilities.cpp:
1590 (JSC::FTL::canCompile):
1591 * ftl/FTLLowerDFGToB3.cpp:
1592 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1593 (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
1595 2017-10-24 Guillaume Emont <guijemont@igalia.com>
1597 [mips] fix offsets of branches that have to go over a jump
1598 https://bugs.webkit.org/show_bug.cgi?id=153464
1600 The jump() function creates 8 instructions, but the offsets of branches
1601 meant to go over them only account for 6. In most cases, this is not an
1602 issue as the last two instructions of jump() would be nops, but in the
1603 rarer case where the jump destination is in a different 256 MB segment,
1604 MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
1605 the last 4 instructions would be a 2 instruction load (lui/ori) into
1606 $t9, a "j $t9" and then a nop. The wrong offset will mean that the
1607 previous branches meant to go over the whole jump will branch to the
1608 "j $t9" instruction, which would jump to whatever is currently in $t9
1609 (since lui/ori would not be executed).
1611 Reviewed by Michael Catanzaro.
1613 * assembler/MacroAssemblerMIPS.h:
1614 (JSC::MacroAssemblerMIPS::branchAdd32):
1615 (JSC::MacroAssemblerMIPS::branchMul32):
1616 (JSC::MacroAssemblerMIPS::branchSub32):
1617 Fix the offsets of branches meant to go over code generated by jump().
1619 2017-10-24 JF Bastien <jfbastien@apple.com>
1621 WebAssembly: NFC renames of things that aren't JS-specific
1622 https://bugs.webkit.org/show_bug.cgi?id=178738
1624 Reviewed by Saam Barati.
1626 * wasm/WasmB3IRGenerator.cpp:
1627 (JSC::Wasm::parseAndCompile):
1628 * wasm/WasmB3IRGenerator.h:
1629 * wasm/WasmBBQPlan.cpp:
1630 (JSC::Wasm::BBQPlan::complete):
1631 * wasm/WasmCodeBlock.cpp:
1632 (JSC::Wasm::CodeBlock::CodeBlock):
1633 * wasm/WasmCodeBlock.h:
1634 (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
1635 (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
1636 * wasm/WasmFormat.h:
1637 * wasm/js/JSToWasm.cpp:
1638 (JSC::Wasm::createJSToWasmWrapper):
1639 * wasm/js/WebAssemblyModuleRecord.cpp:
1640 (JSC::WebAssemblyModuleRecord::link):
1641 (JSC::WebAssemblyModuleRecord::evaluate):
1643 2017-10-24 Stephan Szabo <stephan.szabo@sony.com>
1645 [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
1646 https://bugs.webkit.org/show_bug.cgi?id=177279
1648 Reviewed by Yusuke Suzuki.
1650 * shell/PlatformJSCOnly.cmake: Added.
1652 2017-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
1654 [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
1655 https://bugs.webkit.org/show_bug.cgi?id=178308
1657 Reviewed by Mark Lam.
1659 With the change of the spec[1], we now do not need to remember star resolution modules.
1660 We reflect this change to our implementation. Since this change is covered by test262,
1661 this patch improves the score of test262.
1663 We also add logging to ResolveExport to debug it easily.
1665 [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
1667 * runtime/AbstractModuleRecord.cpp:
1668 (JSC::AbstractModuleRecord::ResolveQuery::dump const):
1669 (JSC::AbstractModuleRecord::resolveExportImpl):
1671 2017-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
1673 [JSC] Use emitDumbVirtualCall in 32bit JIT
1674 https://bugs.webkit.org/show_bug.cgi?id=178644
1676 Reviewed by Mark Lam.
1678 This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
1680 * jit/JITCall32_64.cpp:
1681 (JSC::JIT::compileCallEvalSlowCase):
1683 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1685 [JSC] Drop ArityCheckData
1686 https://bugs.webkit.org/show_bug.cgi?id=178648
1688 Reviewed by Mark Lam.
1690 ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
1691 However, use of `thunkToCall` is removed in 64bit environment at r189575.
1693 We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
1694 Since we no longer need to have the above pair, we can remove ArityCheckData too.
1696 * llint/LowLevelInterpreter32_64.asm:
1697 * llint/LowLevelInterpreter64.asm:
1698 * runtime/CommonSlowPaths.cpp:
1699 (JSC::SLOW_PATH_DECL):
1700 (JSC::setupArityCheckData): Deleted.
1701 * runtime/CommonSlowPaths.h:
1706 2017-10-23 Keith Miller <keith_miller@apple.com>
1708 Unreviewed, reland r223866
1710 Didn't break the windows build...
1714 "WebAssembly: topEntryFrame on Wasm::Instance"
1715 https://bugs.webkit.org/show_bug.cgi?id=178690
1716 https://trac.webkit.org/changeset/223866
1719 2017-10-23 Commit Queue <commit-queue@webkit.org>
1721 Unreviewed, rolling out r223866.
1722 https://bugs.webkit.org/show_bug.cgi?id=178699
1724 Probably broke the windows build (Requested by keith_miller on
1729 "WebAssembly: topEntryFrame on Wasm::Instance"
1730 https://bugs.webkit.org/show_bug.cgi?id=178690
1731 https://trac.webkit.org/changeset/223866
1733 2017-10-23 Joseph Pecoraro <pecoraro@apple.com>
1735 Web Inspector: Remove unused Console.setMonitoringXHREnabled
1736 https://bugs.webkit.org/show_bug.cgi?id=178617
1738 Reviewed by Sam Weinig.
1740 * JavaScriptCore.xcodeproj/project.pbxproj:
1742 * inspector/agents/InspectorConsoleAgent.h:
1743 * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1744 * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1745 * inspector/protocol/Console.json:
1746 Removed files and method.
1748 * inspector/JSGlobalObjectInspectorController.cpp:
1749 (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1750 This can use the base ConsoleAgent now.
1752 2017-10-23 JF Bastien <jfbastien@apple.com>
1754 WebAssembly: topEntryFrame on Wasm::Instance
1755 https://bugs.webkit.org/show_bug.cgi?id=178690
1757 Reviewed by Saam Barati.
1759 topEntryFrame is usually on VM, but for a no-VM WebAssembly we
1760 need to hold topEntryFrame elsewhere, and generated code cannot
1761 hard-code where topEntryFrame live. Do this at creation time of
1762 Wasm::Instance, and then generated code will just load from
1763 wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
1764 embedding this is still from VM, so all of the unwinding machinery
1767 * dfg/DFGOSREntry.cpp:
1768 (JSC::DFG::prepareOSREntry):
1769 * dfg/DFGOSRExit.cpp:
1770 (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
1771 (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1772 * ftl/FTLOSRExitCompiler.cpp:
1773 (JSC::FTL::compileStub):
1774 * interpreter/Interpreter.cpp:
1775 (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1776 * jit/AssemblyHelpers.cpp:
1777 (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1778 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1779 * jit/AssemblyHelpers.h:
1780 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1781 The default parameter was never non-defaulted from any of the
1782 callers. The new version calls the impl directly because it
1783 doesn't have VM and doesn't hard-code the address of
1785 * jit/RegisterSet.cpp:
1786 (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
1787 VM because it's not really VM-specific.
1788 * jit/RegisterSet.h:
1790 (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
1792 (JSC::VM::getCTIStub):
1793 * wasm/WasmB3IRGenerator.cpp:
1794 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1795 (JSC::Wasm::B3IRGenerator::addCall):
1796 (JSC::Wasm::B3IRGenerator::addCallIndirect):
1797 * wasm/WasmInstance.cpp:
1798 (JSC::Wasm::Instance::Instance):
1799 * wasm/WasmInstance.h: topEntryFramePointer will eventually live
1800 here for real. Right now it's mirrored in JSWebAssemblyInstance
1801 because that's the acting Context.
1802 (JSC::Wasm::Instance::create):
1803 (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
1804 * wasm/WasmThunks.cpp:
1805 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1806 * wasm/js/JSWebAssemblyInstance.cpp:
1807 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1808 * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
1809 (JSC::JSWebAssemblyInstance::offsetOfCallee):
1810 (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
1811 (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
1812 * wasm/js/WebAssemblyInstanceConstructor.cpp:
1813 (JSC::constructJSWebAssemblyInstance):
1814 * wasm/js/WebAssemblyPrototype.cpp:
1817 2017-10-23 Joseph Pecoraro <pecoraro@apple.com>
1819 Web Inspector: Please support HAR Export for network traffic
1820 https://bugs.webkit.org/show_bug.cgi?id=146692
1821 <rdar://problem/7463672>
1823 Reviewed by Brian Burg.
1825 * inspector/protocol/Network.json:
1826 Add a walltime to each send request.
1828 2017-10-23 Matt Lewis <jlewis3@apple.com>
1830 Unreviewed, rolling out r223820.
1832 This caused a build break on Windows.
1836 "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
1837 https://bugs.webkit.org/show_bug.cgi?id=178617
1838 https://trac.webkit.org/changeset/223820
1840 2017-10-23 Yusuke Suzuki <utatane.tea@gmail.com>
1842 [JSC] Use fastJoin in Array#toString
1843 https://bugs.webkit.org/show_bug.cgi?id=178062
1845 Reviewed by Darin Adler.
1847 Array#toString()'s fast path uses original join operation.
1848 But this should use fastJoin if possible.
1849 This patch adds a fast path using fastJoin in Array#toString.
1850 And we also extend fastJoin to perform fast joining for int32
1855 double-array-to-string 126.6157+-5.8625 ^ 103.7343+-4.4968 ^ definitely 1.2206x faster
1856 int32-array-to-string 64.7792+-2.6524 61.2390+-2.1749 might be 1.0578x faster
1857 contiguous-array-to-string 62.6224+-2.6388 ^ 56.9899+-2.0852 ^ definitely 1.0988x faster
1860 * runtime/ArrayPrototype.cpp:
1862 (JSC::arrayProtoFuncToString):
1863 (JSC::arrayProtoFuncToLocaleString):
1864 * runtime/JSStringJoiner.h:
1865 (JSC::JSStringJoiner::appendWithoutSideEffects):
1866 (JSC::JSStringJoiner::appendInt32):
1867 (JSC::JSStringJoiner::appendDouble):
1869 2017-10-22 Zan Dobersek <zdobersek@igalia.com>
1871 [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
1872 https://bugs.webkit.org/show_bug.cgi?id=178452
1874 Reviewed by Yusuke Suzuki.
1876 * heap/RegisterState.h: Re-enable the custom RegisterState and
1877 ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
1878 cause any crashes nowadays.
1880 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1882 [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
1883 https://bugs.webkit.org/show_bug.cgi?id=178647
1885 Reviewed by Saam Barati.
1887 There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
1888 since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
1889 which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
1890 this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
1893 (JSC::JIT::linkAllSlowCases):
1894 * jit/JITArithmetic.cpp:
1895 (JSC::JIT::emitSlow_op_unsigned):
1896 (JSC::JIT::emit_compareAndJump):
1897 (JSC::JIT::emit_compareAndJumpSlow):
1898 (JSC::JIT::emitSlow_op_inc):
1899 (JSC::JIT::emitSlow_op_dec):
1900 (JSC::JIT::emitSlow_op_mod):
1901 (JSC::JIT::emitSlow_op_negate):
1902 (JSC::JIT::emitSlow_op_bitand):
1903 (JSC::JIT::emitSlow_op_bitor):
1904 (JSC::JIT::emitSlow_op_bitxor):
1905 (JSC::JIT::emitSlow_op_lshift):
1906 (JSC::JIT::emitSlow_op_rshift):
1907 (JSC::JIT::emitSlow_op_urshift):
1908 (JSC::JIT::emitSlow_op_add):
1909 (JSC::JIT::emitSlow_op_div):
1910 (JSC::JIT::emitSlow_op_mul):
1911 (JSC::JIT::emitSlow_op_sub):
1912 * jit/JITArithmetic32_64.cpp:
1913 (JSC::JIT::emit_compareAndJumpSlow):
1914 (JSC::JIT::emitSlow_op_unsigned):
1915 (JSC::JIT::emitSlow_op_inc):
1916 (JSC::JIT::emitSlow_op_dec):
1917 (JSC::JIT::emitSlow_op_mod):
1919 (JSC::JIT::compileCallEvalSlowCase):
1920 (JSC::JIT::compileOpCallSlowCase):
1921 * jit/JITCall32_64.cpp:
1922 (JSC::JIT::compileCallEvalSlowCase):
1923 (JSC::JIT::compileOpCallSlowCase):
1925 (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
1926 * jit/JITOpcodes.cpp:
1927 (JSC::JIT::emitSlow_op_new_object):
1928 (JSC::JIT::emitSlow_op_create_this):
1929 (JSC::JIT::emitSlow_op_check_tdz):
1930 (JSC::JIT::emitSlow_op_to_this):
1931 (JSC::JIT::emitSlow_op_to_primitive):
1932 (JSC::JIT::emitSlow_op_not):
1933 (JSC::JIT::emitSlow_op_eq):
1934 (JSC::JIT::emitSlow_op_neq):
1935 (JSC::JIT::emitSlow_op_stricteq):
1936 (JSC::JIT::emitSlow_op_nstricteq):
1937 (JSC::JIT::emitSlow_op_instanceof):
1938 (JSC::JIT::emitSlow_op_instanceof_custom):
1939 (JSC::JIT::emitSlow_op_to_number):
1940 (JSC::JIT::emitSlow_op_to_string):
1941 (JSC::JIT::emitSlow_op_loop_hint):
1942 (JSC::JIT::emitSlow_op_check_traps):
1943 (JSC::JIT::emitSlow_op_has_indexed_property):
1944 (JSC::JIT::emitSlow_op_get_direct_pname):
1945 (JSC::JIT::emitSlow_op_has_structure_property):
1946 * jit/JITOpcodes32_64.cpp:
1947 (JSC::JIT::emitSlow_op_new_object):
1948 (JSC::JIT::emitSlow_op_instanceof):
1949 (JSC::JIT::emitSlow_op_instanceof_custom):
1950 (JSC::JIT::emitSlow_op_to_primitive):
1951 (JSC::JIT::emitSlow_op_not):
1952 (JSC::JIT::emitSlow_op_stricteq):
1953 (JSC::JIT::emitSlow_op_nstricteq):
1954 (JSC::JIT::emitSlow_op_to_number):
1955 (JSC::JIT::emitSlow_op_to_string):
1956 (JSC::JIT::emitSlow_op_create_this):
1957 (JSC::JIT::emitSlow_op_to_this):
1958 (JSC::JIT::emitSlow_op_check_tdz):
1959 (JSC::JIT::emitSlow_op_has_indexed_property):
1960 (JSC::JIT::emitSlow_op_get_direct_pname):
1961 * jit/JITPropertyAccess.cpp:
1962 (JSC::JIT::emitSlow_op_try_get_by_id):
1963 (JSC::JIT::emitSlow_op_get_by_id):
1964 (JSC::JIT::emitSlow_op_get_by_id_with_this):
1965 (JSC::JIT::emitSlow_op_put_by_id):
1966 (JSC::JIT::emitSlow_op_resolve_scope):
1967 (JSC::JIT::emitSlow_op_get_from_scope):
1968 (JSC::JIT::emitSlow_op_put_to_scope):
1969 * jit/JITPropertyAccess32_64.cpp:
1970 (JSC::JIT::emitSlow_op_try_get_by_id):
1971 (JSC::JIT::emitSlow_op_get_by_id):
1972 (JSC::JIT::emitSlow_op_get_by_id_with_this):
1973 (JSC::JIT::emitSlow_op_put_by_id):
1974 (JSC::JIT::emitSlow_op_resolve_scope):
1975 (JSC::JIT::emitSlow_op_get_from_scope):
1976 (JSC::JIT::emitSlow_op_put_to_scope):
1978 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
1980 [JSC] Clean up baseline slow path
1981 https://bugs.webkit.org/show_bug.cgi?id=178646
1983 Reviewed by Saam Barati.
1985 If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
1986 It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
1987 function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
1988 code in baseline JIT.
1991 (JSC::JIT::privateCompileMainPass):
1993 * jit/JITArithmetic.cpp:
1994 (JSC::JIT::emit_op_pow): Deleted.
1995 * jit/JITArithmetic32_64.cpp:
1996 (JSC::JIT::emitSlow_op_mod):
1997 * jit/JITOpcodes.cpp:
1998 (JSC::JIT::emit_op_strcat): Deleted.
1999 (JSC::JIT::emit_op_push_with_scope): Deleted.
2000 (JSC::JIT::emit_op_assert): Deleted.
2001 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
2002 (JSC::JIT::emit_op_throw_static_error): Deleted.
2003 (JSC::JIT::emit_op_new_array_with_spread): Deleted.
2004 (JSC::JIT::emit_op_spread): Deleted.
2005 (JSC::JIT::emit_op_get_enumerable_length): Deleted.
2006 (JSC::JIT::emit_op_has_generic_property): Deleted.
2007 (JSC::JIT::emit_op_get_property_enumerator): Deleted.
2008 (JSC::JIT::emit_op_to_index_string): Deleted.
2009 (JSC::JIT::emit_op_create_direct_arguments): Deleted.
2010 (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
2011 (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
2012 (JSC::JIT::emit_op_create_rest): Deleted.
2013 (JSC::JIT::emit_op_unreachable): Deleted.
2014 * jit/JITOpcodes32_64.cpp:
2015 (JSC::JIT::emit_op_strcat): Deleted.
2016 (JSC::JIT::emit_op_push_with_scope): Deleted.
2017 (JSC::JIT::emit_op_assert): Deleted.
2018 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
2019 * jit/JITPropertyAccess.cpp:
2020 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
2021 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
2022 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
2023 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
2024 (JSC::JIT::emit_op_define_data_property): Deleted.
2025 (JSC::JIT::emit_op_define_accessor_property): Deleted.
2026 * jit/JITPropertyAccess32_64.cpp:
2027 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
2028 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
2029 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
2030 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
2032 2017-10-21 Joseph Pecoraro <pecoraro@apple.com>
2034 Web Inspector: Remove unused Console.setMonitoringXHREnabled
2035 https://bugs.webkit.org/show_bug.cgi?id=178617
2037 Reviewed by Sam Weinig.
2039 * JavaScriptCore.xcodeproj/project.pbxproj:
2041 * inspector/agents/InspectorConsoleAgent.h:
2042 * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
2043 * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
2044 * inspector/protocol/Console.json:
2045 Removed files and method.
2047 * inspector/JSGlobalObjectInspectorController.cpp:
2048 (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2049 This can use the base ConsoleAgent now.
2051 2017-10-21 Yusuke Suzuki <utatane.tea@gmail.com>
2053 [JSC] Remove per-host-function CTI stub in 32bit environment
2054 https://bugs.webkit.org/show_bug.cgi?id=178581
2056 Reviewed by Saam Barati.
2058 JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
2059 The only difference is that it embed the address of the host function directly in the generated stub. This means
2060 that we have per-host-function CTI stub only in 32bit environment.
2062 This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
2065 (JSC::JIT::compileCTINativeCall): Deleted.
2067 * jit/JITOpcodes.cpp:
2068 (JSC::JIT::privateCompileCTINativeCall): Deleted.
2069 * jit/JITOpcodes32_64.cpp:
2070 (JSC::JIT::privateCompileCTINativeCall): Deleted.
2071 * jit/JITThunks.cpp:
2072 (JSC::JITThunks::hostFunctionStub):
2074 2017-10-20 Antoine Quint <graouts@apple.com>
2076 [Web Animations] Provide basic timeline and animation interfaces
2077 https://bugs.webkit.org/show_bug.cgi?id=178526
2079 Reviewed by Dean Jackson.
2081 Remove the WEB_ANIMATIONS compile-time flag.
2083 * Configurations/FeatureDefines.xcconfig:
2085 2017-10-20 Commit Queue <commit-queue@webkit.org>
2087 Unreviewed, rolling out r223744, r223750, and r223751.
2088 https://bugs.webkit.org/show_bug.cgi?id=178594
2090 These caused consistent failures in test that existed and were
2091 added in the patches. (Requested by mlewis13 on #webkit).
2093 Reverted changesets:
2095 "[JSC] ScriptFetcher should be notified directly from module
2097 https://bugs.webkit.org/show_bug.cgi?id=178340
2098 https://trac.webkit.org/changeset/223744
2100 "Unreviewed, fix changed line number in test expect files"
2101 https://bugs.webkit.org/show_bug.cgi?id=178340
2102 https://trac.webkit.org/changeset/223750
2104 "Unreviewed, follow up to reflect comments"
2105 https://bugs.webkit.org/show_bug.cgi?id=178340
2106 https://trac.webkit.org/changeset/223751
2108 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2110 Unreviewed, follow up to reflect comments
2111 https://bugs.webkit.org/show_bug.cgi?id=178340
2113 * runtime/JSModuleLoader.cpp:
2114 (JSC::JSModuleLoader::notifyCompleted):
2116 2017-10-20 Saam Barati <sbarati@apple.com>
2118 Optimize accesses to how we get the direct prototype
2119 https://bugs.webkit.org/show_bug.cgi?id=178548
2121 Reviewed by Yusuke Suzuki.
2123 This patch makes JSObject::getPrototypeDirect take VM& as a parameter
2124 so it can use the faster version of the structure accessor function.
2125 The reason for making this change is that JSObjet::getPrototypeDirect
2126 is called on the hot path in property lookup.
2128 * API/JSObjectRef.cpp:
2129 (JSObjectGetPrototype):
2131 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
2132 (WTF::DOMJITGetterBaseJSObject::customGetter):
2133 (functionCreateProxy):
2134 * runtime/ArrayPrototype.cpp:
2135 (JSC::speciesWatchpointIsValid):
2136 * runtime/ErrorInstance.cpp:
2137 (JSC::ErrorInstance::sanitizedToString):
2138 * runtime/JSArray.cpp:
2139 (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
2140 * runtime/JSGlobalObject.cpp:
2141 (JSC::JSGlobalObject::init):
2142 (JSC::lastInPrototypeChain):
2143 (JSC::JSGlobalObject::resetPrototype):
2144 (JSC::JSGlobalObject::finishCreation):
2145 * runtime/JSGlobalObjectInlines.h:
2146 (JSC::JSGlobalObject::objectPrototypeIsSane):
2147 (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
2148 (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2149 * runtime/JSLexicalEnvironment.cpp:
2150 (JSC::JSLexicalEnvironment::getOwnPropertySlot):
2151 * runtime/JSMap.cpp:
2152 (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
2153 * runtime/JSObject.cpp:
2154 (JSC::JSObject::calculatedClassName):
2155 (JSC::JSObject::setPrototypeWithCycleCheck):
2156 (JSC::JSObject::getPrototype):
2157 (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
2158 (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
2159 (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
2160 (JSC::JSObject::prototypeChainMayInterceptStoreTo):
2161 * runtime/JSObject.h:
2162 (JSC::JSObject::finishCreation):
2163 (JSC::JSObject::getPrototypeDirect const):
2164 (JSC::JSObject::getPrototype):
2165 * runtime/JSObjectInlines.h:
2166 (JSC::JSObject::canPerformFastPutInline):
2167 (JSC::JSObject::getPropertySlot):
2168 (JSC::JSObject::getNonIndexPropertySlot):
2169 * runtime/JSProxy.cpp:
2170 (JSC::JSProxy::setTarget):
2171 * runtime/JSSet.cpp:
2172 (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
2173 * runtime/ProgramExecutable.cpp:
2174 (JSC::ProgramExecutable::initializeGlobalProperties):
2175 * runtime/StructureInlines.h:
2176 (JSC::Structure::isValid const):
2178 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2180 [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
2181 https://bugs.webkit.org/show_bug.cgi?id=178379
2183 Reviewed by Saam Barati.
2185 We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
2186 in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
2188 * bytecompiler/NodesCodegen.cpp:
2189 (JSC::BinaryOpNode::emitBytecode):
2191 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
2193 [JSC] ScriptFetcher should be notified directly from module pipeline
2194 https://bugs.webkit.org/show_bug.cgi?id=178340
2196 Reviewed by Sam Weinig.
2198 Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
2199 We setup JSStdFunction to the resulted promise of the module pipeline. It is super
2200 ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
2201 JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
2203 But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
2204 notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
2205 from the module pipeline by observer style.
2207 This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
2208 completion/failure notifications from the module pipeline.
2210 * builtins/ModuleLoaderPrototype.js:
2212 (loadAndEvaluateModule):
2213 * runtime/Completion.cpp:
2215 * runtime/Completion.h:
2216 * runtime/JSModuleLoader.cpp:
2217 (JSC::jsValueToModuleKey):
2218 (JSC::JSModuleLoader::notifyCompleted):
2219 (JSC::JSModuleLoader::notifyFailed):
2220 * runtime/JSModuleLoader.h:
2221 * runtime/ModuleLoaderPrototype.cpp:
2222 (JSC::moduleLoaderPrototypeNotifyCompleted):
2223 (JSC::moduleLoaderPrototypeNotifyFailed):
2224 * runtime/ScriptFetcher.h:
2225 (JSC::ScriptFetcher::notifyLoadCompleted):
2226 (JSC::ScriptFetcher::notifyLoadFailed):
2228 2017-10-19 JF Bastien <jfbastien@apple.com>
2230 WebAssembly: no VM / JS version of everything but Instance
2231 https://bugs.webkit.org/show_bug.cgi?id=177473
2233 Reviewed by Filip Pizlo, Saam Barati.
2235 This change entails cleaning up and splitting a bunch of code which we had
2236 intertwined between C++ classes which represent JS objects, and pure C++
2237 implementation objects. This specific change goes most of the way towards
2238 allowing JSC's WebAssembly to work without VM / JS, up to but excluding
2239 JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
2240 yet). Because of this we still have a few FIXME identifying places that need to
2241 change. A follow-up change will go the rest of the way.
2243 I went about this change in the simplest way possible: grep the
2244 JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
2245 sub-directory (which contains the JS implementation of WebAssembly).
2247 None of this change removes the need for a JIT entitlement to be able to use
2248 WebAssembly. We don't have an interpreter, the process therefore still needs to
2249 be allowed to JIT to use these pure-C++ APIs.
2251 Interesting things to note:
2253 - Remove VM from Plan and associated places. It can just live as a capture in
2254 the callback lambda if it's needed.
2255 - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
2256 collect. We now instead pass two lambdas at construction time for this
2257 purpose: one to notify of memory pressure, and the other to ask for
2258 syncrhonous memory reclamation. This allows whoever creates the memory to
2259 dictate how to react to both these cases, and for a JS embedding that's to
2260 call the GC (async or sync, respectively).
2261 - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
2262 there, with an enum class for failure types.
2263 - Exceeding max on memory growth now returns a range error as per spec. This
2264 is a (very minor) breaking change: it used to throw OOM error. Update the
2266 - When generating the grow_memory opcode, no need to get the VM. Instead,
2267 reach directly for Wasm::Memory and grow it.
2268 - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
2269 ever called from JS (not from grow_memory as before).
2270 - Wasm::Memory now takes a callback for successful growth. This allows JS
2271 wrappers to register themselves when growth succeeds without Wasm::Memory
2272 knowning anything about JS. It'll also allow creating a list of callbacks
2273 for when we add thread support (we'll want to notify many wrappers, all
2275 - Wasm::Memory is now back to being the source of truth about address / size,
2276 used directly by generated code instead of JSWebAssemblyMemory.
2277 - Move wasmToJS from the general WasmBinding header to its own header under
2278 wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
2279 and therefore isn't general WebAssembly.
2280 - Make Wasm::Context an actual type (just a struct holding a
2281 JSWebAssemlyInstance for now) instead of an alias for that. Notably this
2282 doesn't add anything to the Context and doesn't change what actually gets
2283 passed around in JIT code (fast TLS or registers) because these changes
2284 potentially impact performance. The entire purpose of this change is to
2285 allow passing Wasm::Context around without having to know about VM. Since VM
2286 contains a Wasm::Context the JS embedding is effectively the same, but with
2287 this setup a non-JS embedding is much better off.
2288 - Move JSWebAssembly into the JS folder.
2289 - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
2290 - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
2291 being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
2292 stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
2293 called wasm->JS stub. This move means that the embedder must, after creating
2294 a Wasm::CodeBlock, somehow create the stubs to call back into the
2295 embedder. This removes an indirection in the generated code because
2296 the B3 IR generator now reaches into the instance instead of
2297 JSWebAssemblyCodeBlock.
2298 - Move more CodeBlock things. Compilation completion is now marked by its own
2299 atomic<bool> flag instead of a nullptr plan: that required using a lock, and
2300 was causing a deadlock in stack-trace.js because before my changes
2301 JSWebAssemblyCodeBlock did its own completion checking separately from
2302 Wasm::CodeBlock, without getting the lock. Now that everything points to
2303 Wasm::CodeBlock and there's no cached completion marker, the lock was being
2304 acquired in a sanity-check assertion.
2305 - Embedder -> Wasm wrappers are now generated through a function that's passed
2306 in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
2307 - WasmMemory doens't need to know about fault handling thunks. Only the IR
2308 generator should know, and should make sure that the exception throwing
2309 thunk is generated if any memory is present (note: with signal handling not
2310 all of them generate an exception check).
2311 - Make exception throwing pluggable: instead of having a hard-coded
2312 JS-specific lambda we now have a regular C++ function being called from JIT
2313 code when a WebAssembly exception is thrown. This allows any embedder to get
2314 called as they wish. For now a process can only have a single of these
2315 functions (i.e. only one embedder per process) because the trap handler is a
2316 singleton. That can be fixed in in #177475.
2317 - Create WasmEmbedder.h where all embedder plugging will live.
2318 - Split up JSWebAssemblyTable into Wasm::Table which is
2319 refcounted. JSWebAssemblyTable now only contains the JS functions in the
2320 table, and Wasm::Table is what's used by the JIT code to lookup where to
2321 call and do the instance check (for context switch). Note that this creates
2322 an extra allocation for all the instances in Wasm::Table, and in exchange
2323 removes an indirection in JIT code because the instance used to be obtained
2324 off of the JS function. Also note that it's the embedder than keeps the
2325 instances alive, not Wasm::Table (which holds a dumb pointer to the
2326 instance), because doing otherwise would cause reference cycles.
2327 - Add WasmInstance. It doesn't do much for now, owns globals.
2328 - JSWebAssembly instance now doesn't just contain the imported functions as
2329 JSObjects, it also has the corresponding import's instance and wasm
2330 entrypoint. This triples the space allocated per instance's imported
2331 function, but there shouldn't be that many imports. This has two upsides: it
2332 creates smaller and faster code, and makes is easier to disassociate
2333 embedder-specific things from embedder-neutral things. The small / faster
2334 win is in two places: B3 IR generator only needs offsetOfImportFunction for
2335 the call opcode (when the called index is an import) to know whether the
2336 import is wasm->wasm or wasm->embedder (this isn't known at compile-time
2337 because it's dependent on the import object), this is now done by seeing if
2338 that import function has an associated target instance (only wasm->wasm
2339 does); the other place is wasmBinding which uses offsetOfImportFunction to
2340 figure out the wasm->wasm target instance, and then gets
2341 WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
2342 call. The disassociation comes because the target instance can be
2343 Wasm::Instance once we change what the Context is, and
2344 WasmEntrypointLoadLocation is already embedder-independent. As a next step I
2345 can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
2346 and leave importFunction in as an opaque pointer which is embedder-specific,
2347 and in JS will remain WriteBarrier<JSObject>.
2348 - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
2349 around instead of VM. This is a first step in allowing entry frames which
2350 aren't stored on VM, but which are instead stored in an embedder-specific
2351 location. That change won't really affect JS except through code churn, but
2352 will allow WebAssembly to use some machinery in a generic manner without
2355 * JavaScriptCore.xcodeproj/project.pbxproj:
2357 * bytecode/PolymorphicAccess.cpp:
2358 (JSC::AccessGenerationState::emitExplicitExceptionHandler):
2359 * debugger/Debugger.cpp:
2360 (JSC::Debugger::stepOutOfFunction):
2361 (JSC::Debugger::returnEvent):
2362 (JSC::Debugger::unwindEvent):
2363 (JSC::Debugger::didExecuteProgram):
2364 * dfg/DFGJITCompiler.cpp:
2365 (JSC::DFG::JITCompiler::compileExceptionHandlers):
2366 * dfg/DFGOSREntry.cpp:
2367 (JSC::DFG::prepareOSREntry):
2368 * dfg/DFGOSRExit.cpp:
2369 (JSC::DFG::OSRExit::compileOSRExit):
2370 (JSC::DFG::OSRExit::compileExit):
2371 * dfg/DFGThunks.cpp:
2372 (JSC::DFG::osrEntryThunkGenerator):
2373 * ftl/FTLCompile.cpp:
2374 (JSC::FTL::compile):
2377 * ftl/FTLLowerDFGToB3.cpp:
2378 (JSC::FTL::DFG::LowerDFGToB3::lower):
2379 * ftl/FTLOSRExitCompiler.cpp:
2380 (JSC::FTL::compileStub):
2381 * interpreter/CallFrame.cpp:
2382 (JSC::CallFrame::wasmAwareLexicalGlobalObject):
2383 (JSC::CallFrame::callerFrame):
2384 (JSC::CallFrame::unsafeCallerFrame):
2385 * interpreter/CallFrame.h:
2386 (JSC::ExecState::callerFrame const):
2387 (JSC::ExecState::callerFrameOrEntryFrame const):
2388 (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
2389 * interpreter/FrameTracers.h:
2390 (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
2391 (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
2392 (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
2393 * interpreter/Interpreter.cpp:
2394 (JSC::UnwindFunctor::operator() const):
2395 (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
2396 (JSC::Interpreter::unwind):
2397 * interpreter/StackVisitor.cpp:
2398 (JSC::StackVisitor::StackVisitor):
2399 (JSC::StackVisitor::gotoNextFrame):
2400 (JSC::StackVisitor::readNonInlinedFrame):
2401 (JSC::StackVisitor::Frame::dump const):
2402 * interpreter/StackVisitor.h:
2403 (JSC::StackVisitor::Frame::callerIsEntryFrame const):
2404 * interpreter/VMEntryRecord.h:
2405 (JSC::VMEntryRecord::prevTopEntryFrame):
2406 (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
2407 (JSC::EntryFrame::vmEntryRecordOffset):
2408 * jit/AssemblyHelpers.cpp:
2409 (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
2410 (JSC::AssemblyHelpers::loadWasmContextInstance):
2411 (JSC::AssemblyHelpers::storeWasmContextInstance):
2412 (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
2413 (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
2414 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
2415 * jit/AssemblyHelpers.h:
2416 (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2417 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
2418 (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
2420 (JSC::JIT::emitEnterOptimizationCheck):
2421 (JSC::JIT::privateCompileExceptionHandlers):
2422 * jit/JITExceptions.cpp:
2423 (JSC::genericUnwind):
2424 * jit/JITOpcodes.cpp:
2425 (JSC::JIT::emit_op_throw):
2426 (JSC::JIT::emit_op_catch):
2427 (JSC::JIT::emitSlow_op_loop_hint):
2428 * jit/JITOpcodes32_64.cpp:
2429 (JSC::JIT::emit_op_throw):
2430 (JSC::JIT::emit_op_catch):
2431 * jit/JITOperations.cpp:
2432 * jit/ThunkGenerators.cpp:
2433 (JSC::throwExceptionFromCallSlowPathGenerator):
2434 (JSC::nativeForGenerator):
2436 (functionDumpCallFrame):
2437 * llint/LLIntSlowPaths.cpp:
2438 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2439 * llint/LLIntThunks.cpp:
2440 (JSC::vmEntryRecord):
2441 * llint/LowLevelInterpreter.asm:
2442 * llint/LowLevelInterpreter32_64.asm:
2443 * llint/LowLevelInterpreter64.asm:
2444 * runtime/Options.cpp:
2445 (JSC::recomputeDependentOptions):
2446 * runtime/Options.h:
2447 * runtime/SamplingProfiler.cpp:
2448 (JSC::FrameWalker::FrameWalker):
2449 (JSC::FrameWalker::advanceToParentFrame):
2450 (JSC::SamplingProfiler::processUnverifiedStackTraces):
2451 * runtime/ThrowScope.cpp:
2452 (JSC::ThrowScope::~ThrowScope):
2457 (JSC::VM::topEntryFrameOffset):
2458 * runtime/VMTraps.cpp:
2460 (JSC::VMTraps::tryInstallTrapBreakpoints):
2461 (JSC::VMTraps::invalidateCodeBlocksOnStack):
2462 * wasm/WasmB3IRGenerator.cpp:
2463 (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
2464 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2465 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2466 (JSC::Wasm::B3IRGenerator::addGrowMemory):
2467 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
2468 (JSC::Wasm::B3IRGenerator::addCall):
2469 (JSC::Wasm::B3IRGenerator::addCallIndirect):
2470 (JSC::Wasm::parseAndCompile):
2471 * wasm/WasmB3IRGenerator.h:
2472 * wasm/WasmBBQPlan.cpp:
2473 (JSC::Wasm::BBQPlan::BBQPlan):
2474 (JSC::Wasm::BBQPlan::compileFunctions):
2475 (JSC::Wasm::BBQPlan::complete):
2476 * wasm/WasmBBQPlan.h:
2477 * wasm/WasmBBQPlanInlines.h:
2478 (JSC::Wasm::BBQPlan::initializeCallees):
2479 * wasm/WasmBinding.cpp:
2480 (JSC::Wasm::wasmToWasm):
2481 * wasm/WasmBinding.h:
2482 * wasm/WasmCodeBlock.cpp:
2483 (JSC::Wasm::CodeBlock::create):
2484 (JSC::Wasm::CodeBlock::CodeBlock):
2485 (JSC::Wasm::CodeBlock::compileAsync):
2486 (JSC::Wasm::CodeBlock::setCompilationFinished):
2487 * wasm/WasmCodeBlock.h:
2488 (JSC::Wasm::CodeBlock::offsetOfImportStubs):
2489 (JSC::Wasm::CodeBlock::allocationSize):
2490 (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
2491 (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
2492 (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
2493 (JSC::Wasm::CodeBlock::compilationFinished):
2494 (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2495 (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2496 * wasm/WasmContext.cpp:
2497 (JSC::Wasm::Context::useFastTLS):
2498 (JSC::Wasm::Context::load const):
2499 (JSC::Wasm::Context::store):
2500 * wasm/WasmContext.h:
2501 * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
2502 * wasm/WasmFaultSignalHandler.cpp:
2503 * wasm/WasmFaultSignalHandler.h:
2504 * wasm/WasmFormat.h:
2505 * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2506 (JSC::Wasm::Instance::Instance):
2507 (JSC::Wasm::Instance::~Instance):
2508 (JSC::Wasm::Instance::extraMemoryAllocated const):
2509 * wasm/WasmInstance.h: Added.
2510 (JSC::Wasm::Instance::create):
2511 (JSC::Wasm::Instance::finalizeCreation):
2512 (JSC::Wasm::Instance::module):
2513 (JSC::Wasm::Instance::codeBlock):
2514 (JSC::Wasm::Instance::memory):
2515 (JSC::Wasm::Instance::table):
2516 (JSC::Wasm::Instance::loadI32Global const):
2517 (JSC::Wasm::Instance::loadI64Global const):
2518 (JSC::Wasm::Instance::loadF32Global const):
2519 (JSC::Wasm::Instance::loadF64Global const):
2520 (JSC::Wasm::Instance::setGlobal):
2521 (JSC::Wasm::Instance::offsetOfCachedStackLimit):
2522 (JSC::Wasm::Instance::cachedStackLimit const):
2523 (JSC::Wasm::Instance::setCachedStackLimit):
2524 * wasm/WasmMemory.cpp:
2525 (JSC::Wasm::Memory::Memory):
2526 (JSC::Wasm::Memory::create):
2527 (JSC::Wasm::Memory::~Memory):
2528 (JSC::Wasm::Memory::grow):
2529 * wasm/WasmMemory.h:
2530 (JSC::Wasm::Memory::offsetOfMemory):
2531 (JSC::Wasm::Memory::offsetOfSize):
2532 * wasm/WasmMemoryInformation.cpp:
2533 (JSC::Wasm::PinnedRegisterInfo::get):
2534 (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
2535 * wasm/WasmMemoryInformation.h:
2536 (JSC::Wasm::PinnedRegisterInfo::toSave const):
2537 * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2538 (JSC::Wasm::makeString):
2539 * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
2540 * wasm/WasmModule.cpp:
2541 (JSC::Wasm::makeValidationCallback):
2542 (JSC::Wasm::Module::validateSync):
2543 (JSC::Wasm::Module::validateAsync):
2544 (JSC::Wasm::Module::getOrCreateCodeBlock):
2545 (JSC::Wasm::Module::compileSync):
2546 (JSC::Wasm::Module::compileAsync):
2547 * wasm/WasmModule.h:
2548 * wasm/WasmModuleParser.cpp:
2549 (JSC::Wasm::ModuleParser::parseTableHelper):
2550 * wasm/WasmOMGPlan.cpp:
2551 (JSC::Wasm::OMGPlan::OMGPlan):
2552 (JSC::Wasm::OMGPlan::runForIndex):
2553 * wasm/WasmOMGPlan.h:
2554 * wasm/WasmPageCount.h:
2555 (JSC::Wasm::PageCount::isValid const):
2556 * wasm/WasmPlan.cpp:
2557 (JSC::Wasm::Plan::Plan):
2558 (JSC::Wasm::Plan::runCompletionTasks):
2559 (JSC::Wasm::Plan::addCompletionTask):
2560 (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
2562 (JSC::Wasm::Plan::dontFinalize):
2563 * wasm/WasmSignature.cpp:
2564 * wasm/WasmSignature.h:
2565 * wasm/WasmTable.cpp: Added.
2566 (JSC::Wasm::Table::create):
2567 (JSC::Wasm::Table::~Table):
2568 (JSC::Wasm::Table::Table):
2569 (JSC::Wasm::Table::grow):
2570 (JSC::Wasm::Table::clearFunction):
2571 (JSC::Wasm::Table::setFunction):
2572 * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
2573 (JSC::Wasm::Table::maximum const):
2574 (JSC::Wasm::Table::size const):
2575 (JSC::Wasm::Table::offsetOfSize):
2576 (JSC::Wasm::Table::offsetOfFunctions):
2577 (JSC::Wasm::Table::offsetOfInstances):
2578 (JSC::Wasm::Table::isValidSize):
2579 * wasm/WasmThunks.cpp:
2580 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2581 (JSC::Wasm::triggerOMGTierUpThunkGenerator):
2582 (JSC::Wasm::Thunks::setThrowWasmException):
2583 (JSC::Wasm::Thunks::throwWasmException):
2584 * wasm/WasmThunks.h:
2585 * wasm/WasmWorklist.cpp:
2586 (JSC::Wasm::Worklist::stopAllPlansForContext):
2587 * wasm/WasmWorklist.h:
2588 * wasm/js/JSToWasm.cpp: Added.
2589 (JSC::Wasm::createJSToWasmWrapper):
2590 * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2591 * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
2592 * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
2593 * wasm/js/JSWebAssemblyCodeBlock.cpp:
2594 (JSC::JSWebAssemblyCodeBlock::create):
2595 (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2596 * wasm/js/JSWebAssemblyCodeBlock.h:
2597 * wasm/js/JSWebAssemblyInstance.cpp:
2598 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2599 (JSC::JSWebAssemblyInstance::finishCreation):
2600 (JSC::JSWebAssemblyInstance::visitChildren):
2601 (JSC::JSWebAssemblyInstance::finalizeCreation):
2602 (JSC::JSWebAssemblyInstance::create):
2603 * wasm/js/JSWebAssemblyInstance.h:
2604 (JSC::JSWebAssemblyInstance::instance):
2605 (JSC::JSWebAssemblyInstance::context const):
2606 (JSC::JSWebAssemblyInstance::table):
2607 (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2608 (JSC::JSWebAssemblyInstance::setMemory):
2609 (JSC::JSWebAssemblyInstance::offsetOfTail):
2610 (JSC::JSWebAssemblyInstance::importFunctionInfo):
2611 (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
2612 (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
2613 (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
2614 (JSC::JSWebAssemblyInstance::importFunction):
2615 (JSC::JSWebAssemblyInstance::internalMemory):
2616 (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
2617 (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
2618 (JSC::JSWebAssemblyInstance::offsetOfCallee):
2619 (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2620 (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
2621 (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
2622 (JSC::JSWebAssemblyInstance::cachedStackLimit const):
2623 (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2624 (JSC::JSWebAssemblyInstance::wasmMemory):
2625 (JSC::JSWebAssemblyInstance::wasmModule):
2626 (JSC::JSWebAssemblyInstance::allocationSize):
2627 (JSC::JSWebAssemblyInstance::module const):
2628 * wasm/js/JSWebAssemblyMemory.cpp:
2629 (JSC::JSWebAssemblyMemory::create):
2630 (JSC::JSWebAssemblyMemory::adopt):
2631 (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
2632 (JSC::JSWebAssemblyMemory::grow):
2633 (JSC::JSWebAssemblyMemory::growSuccessCallback):
2634 * wasm/js/JSWebAssemblyMemory.h:
2635 * wasm/js/JSWebAssemblyModule.cpp:
2636 (JSC::JSWebAssemblyModule::moduleInformation const):
2637 (JSC::JSWebAssemblyModule::exportSymbolTable const):
2638 (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
2639 (JSC::JSWebAssemblyModule::callee const):
2640 (JSC::JSWebAssemblyModule::codeBlock):
2641 (JSC::JSWebAssemblyModule::module):
2642 * wasm/js/JSWebAssemblyModule.h:
2643 * wasm/js/JSWebAssemblyTable.cpp:
2644 (JSC::JSWebAssemblyTable::create):
2645 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2646 (JSC::JSWebAssemblyTable::visitChildren):
2647 (JSC::JSWebAssemblyTable::grow):
2648 (JSC::JSWebAssemblyTable::getFunction):
2649 (JSC::JSWebAssemblyTable::clearFunction):
2650 (JSC::JSWebAssemblyTable::setFunction):
2651 * wasm/js/JSWebAssemblyTable.h:
2652 (JSC::JSWebAssemblyTable::isValidSize):
2653 (JSC::JSWebAssemblyTable::maximum const):
2654 (JSC::JSWebAssemblyTable::size const):
2655 (JSC::JSWebAssemblyTable::table):
2656 * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
2657 (JSC::Wasm::materializeImportJSCell):
2658 (JSC::Wasm::wasmToJS):
2659 (JSC::Wasm::wasmToJSException):
2660 * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
2661 * wasm/js/WebAssemblyFunction.cpp:
2662 (JSC::callWebAssemblyFunction):
2663 * wasm/js/WebAssemblyInstanceConstructor.cpp:
2664 (JSC::constructJSWebAssemblyInstance):
2665 * wasm/js/WebAssemblyMemoryConstructor.cpp:
2666 (JSC::constructJSWebAssemblyMemory):
2667 * wasm/js/WebAssemblyMemoryPrototype.cpp:
2668 (JSC::webAssemblyMemoryProtoFuncGrow):
2669 * wasm/js/WebAssemblyModuleConstructor.cpp:
2670 (JSC::constructJSWebAssemblyModule):
2671 (JSC::WebAssemblyModuleConstructor::createModule):
2672 * wasm/js/WebAssemblyModuleConstructor.h:
2673 * wasm/js/WebAssemblyModuleRecord.cpp:
2674 (JSC::WebAssemblyModuleRecord::link):
2675 (JSC::WebAssemblyModuleRecord::evaluate):
2676 * wasm/js/WebAssemblyPrototype.cpp:
2677 (JSC::webAssemblyCompileFunc):
2679 (JSC::compileAndInstantiate):
2680 (JSC::webAssemblyValidateFunc):
2681 * wasm/js/WebAssemblyTableConstructor.cpp:
2682 (JSC::constructJSWebAssemblyTable):
2683 * wasm/js/WebAssemblyWrapperFunction.cpp:
2684 (JSC::WebAssemblyWrapperFunction::create):
2686 2017-10-19 Mark Lam <mark.lam@apple.com>
2688 Stringifier::appendStringifiedValue() is missing an exception check.
2689 https://bugs.webkit.org/show_bug.cgi?id=178386
2690 <rdar://problem/35027610>
2692 Reviewed by Saam Barati.
2694 * runtime/JSONObject.cpp:
2695 (JSC::Stringifier::appendStringifiedValue):
2697 2017-10-19 Saam Barati <sbarati@apple.com>
2699 REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
2700 https://bugs.webkit.org/show_bug.cgi?id=178543
2702 Reviewed by Filip Pizlo.
2704 * dfg/DFGByteCodeParser.cpp:
2705 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2707 2017-10-19 Saam Barati <sbarati@apple.com>
2709 re-inline ObjectAllocationProfile::initializeProfile
2710 https://bugs.webkit.org/show_bug.cgi?id=178532
2712 Rubber stamped by Michael Saboff.
2714 I un-inlined this function when implementing poly proto.
2715 This patch re-inlines it. In my testing, it looks like it
2716 might be a 0.5% speedometer progression to inline it.
2718 * JavaScriptCore.xcodeproj/project.pbxproj:
2720 * bytecode/CodeBlock.cpp:
2721 * bytecode/ObjectAllocationProfile.cpp: Removed.
2722 * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
2723 (JSC::ObjectAllocationProfile::initializeProfile):
2724 (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
2725 * runtime/FunctionRareData.cpp:
2727 2017-10-19 Michael Saboff <msaboff@apple.com>
2729 Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
2730 https://bugs.webkit.org/show_bug.cgi?id=178521
2732 Reviewed by JF Bastien.
2734 * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
2735 standard version. The prior version was the draft 6.0 version.
2737 2017-10-19 Saam Barati <sbarati@apple.com>
2739 We should hard code the poly proto offset
2740 https://bugs.webkit.org/show_bug.cgi?id=178531
2742 Reviewed by Filip Pizlo.
2744 This patch embraces that the poly proto offset is always zero. It's already
2745 the case that we would always get the inline offset zero for poly proto just
2746 by construction. This just hardcodes this assumption throughout the codebase.
2747 This appears to be a 1% speedometer progression in my testing.
2749 The downside of this patch is that it may require changing how we do
2750 things when we implement poly proto when inheriting from builtin
2751 types. I think we can face this problem when we decide to implement
2754 * bytecode/AccessCase.cpp:
2755 (JSC::AccessCase::generateWithGuard):
2756 * dfg/DFGOperations.cpp:
2757 * dfg/DFGSpeculativeJIT.cpp:
2758 (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2759 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2760 * ftl/FTLLowerDFGToB3.cpp:
2761 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2762 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2763 * jit/JITOpcodes.cpp:
2764 (JSC::JIT::emit_op_instanceof):
2765 * jit/JITOpcodes32_64.cpp:
2766 (JSC::JIT::emit_op_instanceof):
2767 * runtime/CommonSlowPaths.cpp:
2768 (JSC::SLOW_PATH_DECL):
2769 * runtime/JSObject.cpp:
2770 (JSC::JSObject::setPrototypeDirect):
2771 * runtime/JSObject.h:
2772 (JSC::JSObject::locationForOffset const):
2773 (JSC::JSObject::locationForOffset):
2774 (JSC::JSObject::getDirect const):
2775 * runtime/PropertyOffset.h:
2776 * runtime/Structure.cpp:
2777 (JSC::Structure::create):
2778 (JSC::Structure::dump const):
2779 * runtime/Structure.h:
2780 * runtime/StructureInlines.h:
2781 (JSC::Structure::storedPrototype const):
2782 (JSC::Structure::storedPrototypeObject const):
2784 2017-10-19 Saam Barati <sbarati@apple.com>
2786 Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
2787 https://bugs.webkit.org/show_bug.cgi?id=178529
2789 Reviewed by Mark Lam.
2791 * runtime/Structure.h:
2792 * runtime/StructureInlines.h:
2793 (JSC::Structure::storedPrototypeObject const):
2794 (JSC::Structure::storedPrototypeStructure const):
2795 (JSC::Structure::storedPrototype const):
2796 (JSC::Structure::prototypeForLookup const):
2797 (JSC::Structure::prototypeChain const):
2799 2017-10-19 Saam Barati <sbarati@apple.com>
2801 Turn poly proto back on by default and remove the option
2802 https://bugs.webkit.org/show_bug.cgi?id=178525
2804 Reviewed by Mark Lam.
2806 I added this option because I thought it'd speed speedometer up because the
2807 original poly proto patch slowed speedometer down. It turns out that
2808 allocating poly proto objects is not what slows speedometer down. It's
2809 other code I added in the runtime that needs to be poly proto aware. I'll
2810 be addressing these in follow up patches.
2812 * runtime/Options.h:
2813 * runtime/StructureInlines.h:
2814 (JSC::Structure::shouldConvertToPolyProto):
2816 2017-10-19 Robin Morisset <rmorisset@apple.com>
2818 Turn recursive tail calls into loops
2819 https://bugs.webkit.org/show_bug.cgi?id=176601
2821 Reviewed by Saam Barati.
2823 We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
2824 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.
2825 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.
2826 We do this part through modifying the computation of the jump targets.
2827 Importantly, we only do this splitting for functions that have tail calls.
2828 It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
2830 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.
2831 The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
2833 * bytecode/CodeBlock.h:
2834 (JSC::CodeBlock::hasTailCalls const):
2835 * bytecode/PreciseJumpTargets.cpp:
2836 (JSC::getJumpTargetsForBytecodeOffset):
2837 (JSC::computePreciseJumpTargetsInternal):
2838 * bytecode/UnlinkedCodeBlock.cpp:
2839 (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2840 * bytecode/UnlinkedCodeBlock.h:
2841 (JSC::UnlinkedCodeBlock::hasTailCalls const):
2842 (JSC::UnlinkedCodeBlock::setHasTailCalls):
2843 * bytecompiler/BytecodeGenerator.cpp:
2844 (JSC::BytecodeGenerator::emitEnter):
2845 (JSC::BytecodeGenerator::emitCallInTailPosition):
2846 * dfg/DFGByteCodeParser.cpp:
2847 (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
2848 (JSC::DFG::ByteCodeParser::makeBlockTargetable):
2849 (JSC::DFG::ByteCodeParser::handleCall):
2850 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2851 (JSC::DFG::ByteCodeParser::parseBlock):
2852 (JSC::DFG::ByteCodeParser::parse):
2854 2017-10-18 Mark Lam <mark.lam@apple.com>
2856 RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
2857 https://bugs.webkit.org/show_bug.cgi?id=177600
2858 <rdar://problem/34710985>
2860 Reviewed by Saam Barati.
2862 According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
2863 section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
2864 descriptor value is present.
2866 * runtime/RegExpObject.cpp:
2867 (JSC::RegExpObject::defineOwnProperty):
2869 2017-10-18 Keith Miller <keith_miller@apple.com>
2871 Setup WebCore build to start using unified sources.
2872 https://bugs.webkit.org/show_bug.cgi?id=178362
2874 Reviewed by Tim Horton.
2876 Change comments in source list files. Also, pass explicit names for build files.
2879 * PlatformGTK.cmake:
2880 * PlatformMac.cmake:
2885 2017-10-18 Commit Queue <commit-queue@webkit.org>
2887 Unreviewed, rolling out r223321.
2888 https://bugs.webkit.org/show_bug.cgi?id=178476
2890 This protocol change broke some internal builds (Requested by
2891 brrian__ on #webkit).
2895 "Web Inspector: provide a way to enable/disable event
2897 https://bugs.webkit.org/show_bug.cgi?id=177451
2898 https://trac.webkit.org/changeset/223321
2900 2017-10-18 Mark Lam <mark.lam@apple.com>
2902 The compiler should always register a structure when it adds its transitionWatchPointSet.
2903 https://bugs.webkit.org/show_bug.cgi?id=178420
2904 <rdar://problem/34814024>
2906 Reviewed by Saam Barati and Filip Pizlo.
2908 Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
2909 now invoke Graph::registerAndWatchStructureTransition() on the structure.
2910 registerAndWatchStructureTransition() both registers the structure and add its
2911 transitionWatchpointSet to the plan desired watchpoints.
2913 Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
2914 except registerAndWatchStructureTransition() adds the structure's
2915 transitionWatchpointSet unconditionally.
2917 * dfg/DFGArgumentsEliminationPhase.cpp:
2918 * dfg/DFGArrayMode.cpp:
2919 (JSC::DFG::ArrayMode::refine const):
2920 * dfg/DFGByteCodeParser.cpp:
2921 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2922 * dfg/DFGFixupPhase.cpp:
2923 (JSC::DFG::FixupPhase::fixupNode):
2926 (JSC::DFG::Graph::registerAndWatchStructureTransition):
2929 * dfg/DFGSpeculativeJIT.cpp:
2930 (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2931 - The second set of addLazily()s is redundant. This set is executed only when
2932 prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
2933 only if we've executed the if statement above it. That preceding if statement
2934 already registerAndWatchStructureTransition() the same 2 structures. Hence,
2935 this second set can be deleted.
2937 * dfg/DFGWatchpointCollectionPhase.cpp:
2938 (JSC::DFG::WatchpointCollectionPhase::addLazily):
2939 - Deleted an unused function.
2941 * ftl/FTLLowerDFGToB3.cpp:
2942 (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2944 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
2946 [JSC] Remove unused private name structure
2947 https://bugs.webkit.org/show_bug.cgi?id=178436
2949 Reviewed by Sam Weinig.
2951 It is no longer used. This patch just removes it.
2953 * runtime/JSGlobalObject.h:
2954 (JSC::JSGlobalObject::numberObjectStructure const):
2955 (JSC::JSGlobalObject::privateNameStructure const): Deleted.
2957 2017-10-18 Ryosuke Niwa <rniwa@webkit.org>
2959 Fix macOS and iOS builds after r223594.
2961 * JavaScriptCore.xcodeproj/project.pbxproj:
2963 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
2965 [JSC] __proto__ getter should be fast
2966 https://bugs.webkit.org/show_bug.cgi?id=178067
2968 Reviewed by Saam Barati.
2970 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2971 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2972 Call node for this. It is inefficient since typically we know the `prototype` of the given
2973 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2974 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2975 we can still change this to efficient access to poly proto slot.
2977 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2978 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2979 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2980 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2981 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2984 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2986 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2987 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2988 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2990 This patch improves SixSpeed super.es6 by 3.42x.
2994 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
2996 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2998 * dfg/DFGAbstractInterpreterInlines.h:
2999 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3000 * dfg/DFGByteCodeParser.cpp:
3001 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3002 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
3003 (JSC::DFG::ByteCodeParser::handleGetById):
3004 * dfg/DFGClobberize.h:
3005 (JSC::DFG::clobberize):
3006 * dfg/DFGDoesGC.cpp:
3008 * dfg/DFGFixupPhase.cpp:
3009 (JSC::DFG::FixupPhase::fixupNode):
3010 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
3011 * dfg/DFGHeapLocation.cpp:
3012 (WTF::printInternal):
3013 * dfg/DFGHeapLocation.h:
3015 (JSC::DFG::Node::hasHeapPrediction):
3016 (JSC::DFG::Node::shouldSpeculateFunction):
3017 * dfg/DFGNodeType.h:
3018 * dfg/DFGOperations.cpp:
3019 * dfg/DFGOperations.h:
3020 * dfg/DFGPredictionPropagationPhase.cpp:
3021 * dfg/DFGSafeToExecute.h:
3022 (JSC::DFG::safeToExecute):
3023 * dfg/DFGSpeculativeJIT.cpp:
3024 (JSC::DFG::SpeculativeJIT::speculateFunction):
3025 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
3026 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
3027 * dfg/DFGSpeculativeJIT.h:
3028 (JSC::DFG::SpeculativeJIT::callOperation):
3029 * dfg/DFGSpeculativeJIT32_64.cpp:
3030 (JSC::DFG::SpeculativeJIT::compile):
3031 * dfg/DFGSpeculativeJIT64.cpp:
3032 (JSC::DFG::SpeculativeJIT::compile):
3033 * ftl/FTLCapabilities.cpp:
3034 (JSC::FTL::canCompile):
3035 * ftl/FTLLowerDFGToB3.cpp:
3036 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3037 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
3038 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3039 * jit/IntrinsicEmitter.cpp:
3040 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
3041 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
3042 * jit/JITOperations.h:
3043 * runtime/Intrinsic.cpp:
3044 (JSC::intrinsicName):
3045 * runtime/Intrinsic.h:
3046 * runtime/JSGlobalObject.cpp:
3047 (JSC::JSGlobalObject::init):
3048 * runtime/JSGlobalObject.h:
3049 (JSC::JSGlobalObject::booleanPrototype const):
3050 (JSC::JSGlobalObject::numberPrototype const):
3051 (JSC::JSGlobalObject::booleanObjectStructure const):
3052 * runtime/JSGlobalObjectFunctions.cpp:
3053 (JSC::globalFuncProtoGetter):
3054 * runtime/JSGlobalObjectFunctions.h:
3055 * runtime/ObjectConstructor.cpp:
3056 * runtime/ReflectObject.cpp:
3058 2017-10-17 Ryan Haddad <ryanhaddad@apple.com>
3060 Unreviewed, rolling out r223523.
3062 A test for this change is failing on debug JSC bots.
3066 "[JSC] __proto__ getter should be fast"
3067 https://bugs.webkit.org/show_bug.cgi?id=178067
3068 https://trac.webkit.org/changeset/223523
3070 2017-10-17 Youenn Fablet <youenn@apple.com>
3072 Add preliminary support for fetch event
3073 https://bugs.webkit.org/show_bug.cgi?id=178171
3075 Reviewed by Chris Dumez.
3079 * runtime/JSPromise.h:
3081 2017-10-10 Yusuke Suzuki <utatane.tea@gmail.com>
3083 [JSC] __proto__ getter should be fast
3084 https://bugs.webkit.org/show_bug.cgi?id=178067
3086 Reviewed by Saam Barati.
3088 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
3089 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
3090 Call node for this. It is inefficient since typically we know the `prototype` of the given
3091 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
3092 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
3093 we can still change this to efficient access to poly proto slot.
3095 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
3096 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
3097 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
3098 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
3099 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
3102 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
3104 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
3105 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
3106 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
3108 This patch improves SixSpeed super.es6 by 3.42x.
3112 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
3114 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
3116 * dfg/DFGAbstractInterpreterInlines.h:
3117 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3118 * dfg/DFGByteCodeParser.cpp:
3119 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3120 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
3121 (JSC::DFG::ByteCodeParser::handleGetById):
3122 * dfg/DFGClobberize.h:
3123 (JSC::DFG::clobberize):
3124 * dfg/DFGDoesGC.cpp:
3126 * dfg/DFGFixupPhase.cpp:
3127 (JSC::DFG::FixupPhase::fixupNode):
3128 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
3129 * dfg/DFGHeapLocation.cpp:
3130 (WTF::printInternal):
3131 * dfg/DFGHeapLocation.h:
3133 (JSC::DFG::Node::hasHeapPrediction):
3134 (JSC::DFG::Node::shouldSpeculateFunction):
3135 * dfg/DFGNodeType.h:
3136 * dfg/DFGOperations.cpp:
3137 * dfg/DFGOperations.h:
3138 * dfg/DFGPredictionPropagationPhase.cpp:
3139 * dfg/DFGSafeToExecute.h:
3140 (JSC::DFG::safeToExecute):
3141 * dfg/DFGSpeculativeJIT.cpp:
3142 (JSC::DFG::SpeculativeJIT::speculateFunction):
3143 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
3144 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
3145 * dfg/DFGSpeculativeJIT.h:
3146 * dfg/DFGSpeculativeJIT32_64.cpp:
3147 (JSC::DFG::SpeculativeJIT::compile):
3148 * dfg/DFGSpeculativeJIT64.cpp:
3149 (JSC::DFG::SpeculativeJIT::compile):
3150 * ftl/FTLCapabilities.cpp:
3151 (JSC::FTL::canCompile):
3152 * ftl/FTLLowerDFGToB3.cpp:
3153 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3154 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
3155 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3156 * jit/IntrinsicEmitter.cpp:
3157 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
3158 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
3159 * runtime/Intrinsic.cpp:
3160 (JSC::intrinsicName):
3161 * runtime/Intrinsic.h:
3162 * runtime/JSGlobalObject.cpp:
3163 (JSC::JSGlobalObject::init):
3164 * runtime/JSGlobalObjectFunctions.cpp:
3165 (JSC::globalFuncProtoGetter):
3166 * runtime/JSGlobalObjectFunctions.h:
3167 * runtime/ObjectConstructor.cpp:
3168 * runtime/ReflectObject.cpp:
3170 2017-10-17 Keith Miller <keith_miller@apple.com>
3172 Change WebCore sources to work with unified source builds
3173 https://bugs.webkit.org/show_bug.cgi?id=178229
3175 Rubber stamped by Tim Horton.
3177 * Configurations/FeatureDefines.xcconfig:
3179 2017-10-15 Filip Pizlo <fpizlo@apple.com>
3181 Make some asserts into release asserts
3182 https://bugs.webkit.org/show_bug.cgi?id=178324
3184 Reviewed by Saam Barati.
3186 These asserts are not on perf critical paths, so they might as well be release asserts.
3188 * runtime/DataView.h:
3189 (JSC::DataView::get):
3190 (JSC::DataView::set):
3192 2017-10-16 JF Bastien <jfbastien@apple.com>
3194 JSRunLoopTimer: reduce likely race when used improperly
3195 https://bugs.webkit.org/show_bug.cgi?id=178298
3196 <rdar://problem/32899816>
3198 Reviewed by Saam Barati.
3200 If an API user sets a timer on JSRunLoopTimer, and then racily
3201 destroys the JSRunLoopTimer while the timer is firing then it's
3202 possible for timerDidFire to cause a use-after-free and / or crash
3203 because e.g. m_apiLock becomes a nullptr while timerDidFire is
3204 executing. That results from an invalid use of JSRunLoopTimer, but
3205 we should try to be more resilient for that type of misuse because
3206 it's not necessarily easy to catch by inspection.
3208 With this change the only remaining race is if the timer fires,
3209 and then only timerDidFire's prologue executes, but not the load
3210 of the m_apiLock pointer from `this`. It's a much smaller race.
3212 Separately, I'll reach out to API users who are seemingly misusing
3215 * runtime/JSRunLoopTimer.cpp:
3216 (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
3217 and checks for nullptr. This prevents loading it twice off of
3218 `this` and turns a nullptr deref into "just" a use-after-free.
3219 (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
3220 calling m_vm->unregisterRunLoopTimer(this), which in turn does
3221 CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
3222 timerDidFire from doing much while the timers are un-registered.
3223 ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
3224 releasing the lock, so it needs its own local copy.
3226 2017-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
3228 [JSC] Perform module specifier validation at parsing time
3229 https://bugs.webkit.org/show_bug.cgi?id=178256
3231 Reviewed by Darin Adler.
3233 This patch make module loader's `resolve` operation synchronous. And we validate
3234 module's requested module names when instantiating the module instead of satisfying
3235 module's dependencies. This change is not observable to users. But this is precise
3236 to the spec and this optimizes & simplifies the current module loader a bit by
3237 reducing object allocations.
3239 Previously, we have an object called pair in the module loader. This is pair of
3240 module's name and module's record. And we use it to link one module to dependent
3241 modules. Now, it is replaced with module's registry entry.
3243 We also change our loader functions to take a registry entry instead of a module key.
3244 Previous design is due to the consideration that these APIs may be exposed to users
3245 in whatwg/loader spec. However, this won't happen. This change removes unnecessary
3246 repeatedly hash map lookups.
3248 * builtins/ModuleLoaderPrototype.js:
3249 (globalPrivate.newRegistryEntry):
3251 (requestInstantiate):
3257 (GlobalObject::moduleLoaderResolve):
3258 * runtime/AbstractModuleRecord.cpp:
3259 (JSC::AbstractModuleRecord::finishCreation):
3260 (JSC::AbstractModuleRecord::hostResolveImportedModule):
3261 * runtime/JSGlobalObject.h:
3262 * runtime/JSModuleLoader.cpp:
3263 (JSC::JSModuleLoader::resolveSync):
3264 (JSC::JSModuleLoader::resolve):
3265 * runtime/JSModuleLoader.h:
3266 * runtime/ModuleLoaderPrototype.cpp:
3267 (JSC::moduleLoaderPrototypeResolveSync):
3269 2017-10-14 Devin Rousso <webkit@devinrousso.com>
3271 Web Inspector: provide a way to enable/disable event listeners
3272 https://bugs.webkit.org/show_bug.cgi?id=177451
3274 Reviewed by Joseph Pecoraro.
3276 * inspector/protocol/DOM.json:
3277 Add `setEventListenerDisabled` command that enables/disables a specific event listener
3278 during event dispatch. When a disabled event listener is fired, the listener's callback will
3281 2017-10-14 Yusuke Suzuki <utatane.tea@gmail.com>
3283 Reland "Add Above/Below comparisons for UInt32 patterns"
3284 https://bugs.webkit.org/show_bug.cgi?id=177281
3286 Reviewed by Saam Barati.
3288 We reland this patch without DFGStrengthReduction change to see what causes
3289 regression in the iOS bot.
3291 Sometimes, we would like to have UInt32 operations in JS. While VM does
3292 not support UInt32 nicely, VM supports efficient Int32 operations. As long
3293 as signedness does not matter, we can just perform Int32 operations instead
3294 and recognize its bit pattern as UInt32.
3296 But of course, some operations respect signedness. The most frequently
3297 used one is comparison. Octane/zlib performs UInt32 comparison by performing
3298 `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
3299 UInt32 in Int32 form. And op_unsigned will generate Double value if
3300 the generated Int32 is < 0 (which should be UInt32).
3302 There is a chance for optimization. The given code pattern is the following.
3304 op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
3306 This can be converted to the following.
3308 op_urshift(@1) below:< op_urshift(@2)
3310 The above conversion is nice since
3312 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
3313 this check depends on the value of Int32, dropping this check is not as easy as
3314 removing Int32 edge filters.
3316 2. We can perform unsigned comparison in Int32 form. We do not need to convert
3319 Since the above comparison exists in Octane/zlib's *super* hot path, dropping
3320 op_unsigned offers huge win.
3322 At first, my patch attempts to convert the above thing in DFG pipeline.
3323 However it poses several problems.
3325 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
3326 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
3328 2: UInt32ToNumber(@0)
3330 4: UInt32ToNumber(@1)
3333 we could drop @5's MovHint. But @3 is difficult since @4 can exit.
3335 So, instead, we start introducing a simple optimization in the bytecode compiler.
3336 It performs pattern matching for op_urshift and comparison to drop op_unsigned.
3337 We adds op_below and op_above families to bytecodes. They only accept Int32 and
3338 perform unsigned comparison.