1 2017-10-22 Zan Dobersek <zdobersek@igalia.com>
3 [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
4 https://bugs.webkit.org/show_bug.cgi?id=178452
6 Reviewed by Yusuke Suzuki.
8 * heap/RegisterState.h: Re-enable the custom RegisterState and
9 ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
10 cause any crashes nowadays.
12 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
14 [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
15 https://bugs.webkit.org/show_bug.cgi?id=178647
17 Reviewed by Saam Barati.
19 There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
20 since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
21 which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
22 this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
25 (JSC::JIT::linkAllSlowCases):
26 * jit/JITArithmetic.cpp:
27 (JSC::JIT::emitSlow_op_unsigned):
28 (JSC::JIT::emit_compareAndJump):
29 (JSC::JIT::emit_compareAndJumpSlow):
30 (JSC::JIT::emitSlow_op_inc):
31 (JSC::JIT::emitSlow_op_dec):
32 (JSC::JIT::emitSlow_op_mod):
33 (JSC::JIT::emitSlow_op_negate):
34 (JSC::JIT::emitSlow_op_bitand):
35 (JSC::JIT::emitSlow_op_bitor):
36 (JSC::JIT::emitSlow_op_bitxor):
37 (JSC::JIT::emitSlow_op_lshift):
38 (JSC::JIT::emitSlow_op_rshift):
39 (JSC::JIT::emitSlow_op_urshift):
40 (JSC::JIT::emitSlow_op_add):
41 (JSC::JIT::emitSlow_op_div):
42 (JSC::JIT::emitSlow_op_mul):
43 (JSC::JIT::emitSlow_op_sub):
44 * jit/JITArithmetic32_64.cpp:
45 (JSC::JIT::emit_compareAndJumpSlow):
46 (JSC::JIT::emitSlow_op_unsigned):
47 (JSC::JIT::emitSlow_op_inc):
48 (JSC::JIT::emitSlow_op_dec):
49 (JSC::JIT::emitSlow_op_mod):
51 (JSC::JIT::compileCallEvalSlowCase):
52 (JSC::JIT::compileOpCallSlowCase):
53 * jit/JITCall32_64.cpp:
54 (JSC::JIT::compileCallEvalSlowCase):
55 (JSC::JIT::compileOpCallSlowCase):
57 (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
59 (JSC::JIT::emitSlow_op_new_object):
60 (JSC::JIT::emitSlow_op_create_this):
61 (JSC::JIT::emitSlow_op_check_tdz):
62 (JSC::JIT::emitSlow_op_to_this):
63 (JSC::JIT::emitSlow_op_to_primitive):
64 (JSC::JIT::emitSlow_op_not):
65 (JSC::JIT::emitSlow_op_eq):
66 (JSC::JIT::emitSlow_op_neq):
67 (JSC::JIT::emitSlow_op_stricteq):
68 (JSC::JIT::emitSlow_op_nstricteq):
69 (JSC::JIT::emitSlow_op_instanceof):
70 (JSC::JIT::emitSlow_op_instanceof_custom):
71 (JSC::JIT::emitSlow_op_to_number):
72 (JSC::JIT::emitSlow_op_to_string):
73 (JSC::JIT::emitSlow_op_loop_hint):
74 (JSC::JIT::emitSlow_op_check_traps):
75 (JSC::JIT::emitSlow_op_has_indexed_property):
76 (JSC::JIT::emitSlow_op_get_direct_pname):
77 (JSC::JIT::emitSlow_op_has_structure_property):
78 * jit/JITOpcodes32_64.cpp:
79 (JSC::JIT::emitSlow_op_new_object):
80 (JSC::JIT::emitSlow_op_instanceof):
81 (JSC::JIT::emitSlow_op_instanceof_custom):
82 (JSC::JIT::emitSlow_op_to_primitive):
83 (JSC::JIT::emitSlow_op_not):
84 (JSC::JIT::emitSlow_op_stricteq):
85 (JSC::JIT::emitSlow_op_nstricteq):
86 (JSC::JIT::emitSlow_op_to_number):
87 (JSC::JIT::emitSlow_op_to_string):
88 (JSC::JIT::emitSlow_op_create_this):
89 (JSC::JIT::emitSlow_op_to_this):
90 (JSC::JIT::emitSlow_op_check_tdz):
91 (JSC::JIT::emitSlow_op_has_indexed_property):
92 (JSC::JIT::emitSlow_op_get_direct_pname):
93 * jit/JITPropertyAccess.cpp:
94 (JSC::JIT::emitSlow_op_try_get_by_id):
95 (JSC::JIT::emitSlow_op_get_by_id):
96 (JSC::JIT::emitSlow_op_get_by_id_with_this):
97 (JSC::JIT::emitSlow_op_put_by_id):
98 (JSC::JIT::emitSlow_op_resolve_scope):
99 (JSC::JIT::emitSlow_op_get_from_scope):
100 (JSC::JIT::emitSlow_op_put_to_scope):
101 * jit/JITPropertyAccess32_64.cpp:
102 (JSC::JIT::emitSlow_op_try_get_by_id):
103 (JSC::JIT::emitSlow_op_get_by_id):
104 (JSC::JIT::emitSlow_op_get_by_id_with_this):
105 (JSC::JIT::emitSlow_op_put_by_id):
106 (JSC::JIT::emitSlow_op_resolve_scope):
107 (JSC::JIT::emitSlow_op_get_from_scope):
108 (JSC::JIT::emitSlow_op_put_to_scope):
110 2017-10-22 Yusuke Suzuki <utatane.tea@gmail.com>
112 [JSC] Clean up baseline slow path
113 https://bugs.webkit.org/show_bug.cgi?id=178646
115 Reviewed by Saam Barati.
117 If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
118 It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
119 function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
120 code in baseline JIT.
123 (JSC::JIT::privateCompileMainPass):
125 * jit/JITArithmetic.cpp:
126 (JSC::JIT::emit_op_pow): Deleted.
127 * jit/JITArithmetic32_64.cpp:
128 (JSC::JIT::emitSlow_op_mod):
129 * jit/JITOpcodes.cpp:
130 (JSC::JIT::emit_op_strcat): Deleted.
131 (JSC::JIT::emit_op_push_with_scope): Deleted.
132 (JSC::JIT::emit_op_assert): Deleted.
133 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
134 (JSC::JIT::emit_op_throw_static_error): Deleted.
135 (JSC::JIT::emit_op_new_array_with_spread): Deleted.
136 (JSC::JIT::emit_op_spread): Deleted.
137 (JSC::JIT::emit_op_get_enumerable_length): Deleted.
138 (JSC::JIT::emit_op_has_generic_property): Deleted.
139 (JSC::JIT::emit_op_get_property_enumerator): Deleted.
140 (JSC::JIT::emit_op_to_index_string): Deleted.
141 (JSC::JIT::emit_op_create_direct_arguments): Deleted.
142 (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
143 (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
144 (JSC::JIT::emit_op_create_rest): Deleted.
145 (JSC::JIT::emit_op_unreachable): Deleted.
146 * jit/JITOpcodes32_64.cpp:
147 (JSC::JIT::emit_op_strcat): Deleted.
148 (JSC::JIT::emit_op_push_with_scope): Deleted.
149 (JSC::JIT::emit_op_assert): Deleted.
150 (JSC::JIT::emit_op_create_lexical_environment): Deleted.
151 * jit/JITPropertyAccess.cpp:
152 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
153 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
154 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
155 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
156 (JSC::JIT::emit_op_define_data_property): Deleted.
157 (JSC::JIT::emit_op_define_accessor_property): Deleted.
158 * jit/JITPropertyAccess32_64.cpp:
159 (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
160 (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
161 (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
162 (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
164 2017-10-21 Joseph Pecoraro <pecoraro@apple.com>
166 Web Inspector: Remove unused Console.setMonitoringXHREnabled
167 https://bugs.webkit.org/show_bug.cgi?id=178617
169 Reviewed by Sam Weinig.
171 * JavaScriptCore.xcodeproj/project.pbxproj:
173 * inspector/agents/InspectorConsoleAgent.h:
174 * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
175 * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
176 * inspector/protocol/Console.json:
177 Removed files and method.
179 * inspector/JSGlobalObjectInspectorController.cpp:
180 (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
181 This can use the base ConsoleAgent now.
183 2017-10-21 Yusuke Suzuki <utatane.tea@gmail.com>
185 [JSC] Remove per-host-function CTI stub in 32bit environment
186 https://bugs.webkit.org/show_bug.cgi?id=178581
188 Reviewed by Saam Barati.
190 JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
191 The only difference is that it embed the address of the host function directly in the generated stub. This means
192 that we have per-host-function CTI stub only in 32bit environment.
194 This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
197 (JSC::JIT::compileCTINativeCall): Deleted.
199 * jit/JITOpcodes.cpp:
200 (JSC::JIT::privateCompileCTINativeCall): Deleted.
201 * jit/JITOpcodes32_64.cpp:
202 (JSC::JIT::privateCompileCTINativeCall): Deleted.
204 (JSC::JITThunks::hostFunctionStub):
206 2017-10-20 Antoine Quint <graouts@apple.com>
208 [Web Animations] Provide basic timeline and animation interfaces
209 https://bugs.webkit.org/show_bug.cgi?id=178526
211 Reviewed by Dean Jackson.
213 Remove the WEB_ANIMATIONS compile-time flag.
215 * Configurations/FeatureDefines.xcconfig:
217 2017-10-20 Commit Queue <commit-queue@webkit.org>
219 Unreviewed, rolling out r223744, r223750, and r223751.
220 https://bugs.webkit.org/show_bug.cgi?id=178594
222 These caused consistent failures in test that existed and were
223 added in the patches. (Requested by mlewis13 on #webkit).
227 "[JSC] ScriptFetcher should be notified directly from module
229 https://bugs.webkit.org/show_bug.cgi?id=178340
230 https://trac.webkit.org/changeset/223744
232 "Unreviewed, fix changed line number in test expect files"
233 https://bugs.webkit.org/show_bug.cgi?id=178340
234 https://trac.webkit.org/changeset/223750
236 "Unreviewed, follow up to reflect comments"
237 https://bugs.webkit.org/show_bug.cgi?id=178340
238 https://trac.webkit.org/changeset/223751
240 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
242 Unreviewed, follow up to reflect comments
243 https://bugs.webkit.org/show_bug.cgi?id=178340
245 * runtime/JSModuleLoader.cpp:
246 (JSC::JSModuleLoader::notifyCompleted):
248 2017-10-20 Saam Barati <sbarati@apple.com>
250 Optimize accesses to how we get the direct prototype
251 https://bugs.webkit.org/show_bug.cgi?id=178548
253 Reviewed by Yusuke Suzuki.
255 This patch makes JSObject::getPrototypeDirect take VM& as a parameter
256 so it can use the faster version of the structure accessor function.
257 The reason for making this change is that JSObjet::getPrototypeDirect
258 is called on the hot path in property lookup.
260 * API/JSObjectRef.cpp:
261 (JSObjectGetPrototype):
263 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
264 (WTF::DOMJITGetterBaseJSObject::customGetter):
265 (functionCreateProxy):
266 * runtime/ArrayPrototype.cpp:
267 (JSC::speciesWatchpointIsValid):
268 * runtime/ErrorInstance.cpp:
269 (JSC::ErrorInstance::sanitizedToString):
270 * runtime/JSArray.cpp:
271 (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
272 * runtime/JSGlobalObject.cpp:
273 (JSC::JSGlobalObject::init):
274 (JSC::lastInPrototypeChain):
275 (JSC::JSGlobalObject::resetPrototype):
276 (JSC::JSGlobalObject::finishCreation):
277 * runtime/JSGlobalObjectInlines.h:
278 (JSC::JSGlobalObject::objectPrototypeIsSane):
279 (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
280 (JSC::JSGlobalObject::stringPrototypeChainIsSane):
281 * runtime/JSLexicalEnvironment.cpp:
282 (JSC::JSLexicalEnvironment::getOwnPropertySlot):
284 (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
285 * runtime/JSObject.cpp:
286 (JSC::JSObject::calculatedClassName):
287 (JSC::JSObject::setPrototypeWithCycleCheck):
288 (JSC::JSObject::getPrototype):
289 (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
290 (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
291 (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
292 (JSC::JSObject::prototypeChainMayInterceptStoreTo):
293 * runtime/JSObject.h:
294 (JSC::JSObject::finishCreation):
295 (JSC::JSObject::getPrototypeDirect const):
296 (JSC::JSObject::getPrototype):
297 * runtime/JSObjectInlines.h:
298 (JSC::JSObject::canPerformFastPutInline):
299 (JSC::JSObject::getPropertySlot):
300 (JSC::JSObject::getNonIndexPropertySlot):
301 * runtime/JSProxy.cpp:
302 (JSC::JSProxy::setTarget):
304 (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
305 * runtime/ProgramExecutable.cpp:
306 (JSC::ProgramExecutable::initializeGlobalProperties):
307 * runtime/StructureInlines.h:
308 (JSC::Structure::isValid const):
310 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
312 [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
313 https://bugs.webkit.org/show_bug.cgi?id=178379
315 Reviewed by Saam Barati.
317 We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
318 in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
320 * bytecompiler/NodesCodegen.cpp:
321 (JSC::BinaryOpNode::emitBytecode):
323 2017-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
325 [JSC] ScriptFetcher should be notified directly from module pipeline
326 https://bugs.webkit.org/show_bug.cgi?id=178340
328 Reviewed by Sam Weinig.
330 Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
331 We setup JSStdFunction to the resulted promise of the module pipeline. It is super
332 ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
333 JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
335 But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
336 notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
337 from the module pipeline by observer style.
339 This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
340 completion/failure notifications from the module pipeline.
342 * builtins/ModuleLoaderPrototype.js:
344 (loadAndEvaluateModule):
345 * runtime/Completion.cpp:
347 * runtime/Completion.h:
348 * runtime/JSModuleLoader.cpp:
349 (JSC::jsValueToModuleKey):
350 (JSC::JSModuleLoader::notifyCompleted):
351 (JSC::JSModuleLoader::notifyFailed):
352 * runtime/JSModuleLoader.h:
353 * runtime/ModuleLoaderPrototype.cpp:
354 (JSC::moduleLoaderPrototypeNotifyCompleted):
355 (JSC::moduleLoaderPrototypeNotifyFailed):
356 * runtime/ScriptFetcher.h:
357 (JSC::ScriptFetcher::notifyLoadCompleted):
358 (JSC::ScriptFetcher::notifyLoadFailed):
360 2017-10-19 JF Bastien <jfbastien@apple.com>
362 WebAssembly: no VM / JS version of everything but Instance
363 https://bugs.webkit.org/show_bug.cgi?id=177473
365 Reviewed by Filip Pizlo, Saam Barati.
367 This change entails cleaning up and splitting a bunch of code which we had
368 intertwined between C++ classes which represent JS objects, and pure C++
369 implementation objects. This specific change goes most of the way towards
370 allowing JSC's WebAssembly to work without VM / JS, up to but excluding
371 JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
372 yet). Because of this we still have a few FIXME identifying places that need to
373 change. A follow-up change will go the rest of the way.
375 I went about this change in the simplest way possible: grep the
376 JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
377 sub-directory (which contains the JS implementation of WebAssembly).
379 None of this change removes the need for a JIT entitlement to be able to use
380 WebAssembly. We don't have an interpreter, the process therefore still needs to
381 be allowed to JIT to use these pure-C++ APIs.
383 Interesting things to note:
385 - Remove VM from Plan and associated places. It can just live as a capture in
386 the callback lambda if it's needed.
387 - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
388 collect. We now instead pass two lambdas at construction time for this
389 purpose: one to notify of memory pressure, and the other to ask for
390 syncrhonous memory reclamation. This allows whoever creates the memory to
391 dictate how to react to both these cases, and for a JS embedding that's to
392 call the GC (async or sync, respectively).
393 - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
394 there, with an enum class for failure types.
395 - Exceeding max on memory growth now returns a range error as per spec. This
396 is a (very minor) breaking change: it used to throw OOM error. Update the
398 - When generating the grow_memory opcode, no need to get the VM. Instead,
399 reach directly for Wasm::Memory and grow it.
400 - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
401 ever called from JS (not from grow_memory as before).
402 - Wasm::Memory now takes a callback for successful growth. This allows JS
403 wrappers to register themselves when growth succeeds without Wasm::Memory
404 knowning anything about JS. It'll also allow creating a list of callbacks
405 for when we add thread support (we'll want to notify many wrappers, all
407 - Wasm::Memory is now back to being the source of truth about address / size,
408 used directly by generated code instead of JSWebAssemblyMemory.
409 - Move wasmToJS from the general WasmBinding header to its own header under
410 wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
411 and therefore isn't general WebAssembly.
412 - Make Wasm::Context an actual type (just a struct holding a
413 JSWebAssemlyInstance for now) instead of an alias for that. Notably this
414 doesn't add anything to the Context and doesn't change what actually gets
415 passed around in JIT code (fast TLS or registers) because these changes
416 potentially impact performance. The entire purpose of this change is to
417 allow passing Wasm::Context around without having to know about VM. Since VM
418 contains a Wasm::Context the JS embedding is effectively the same, but with
419 this setup a non-JS embedding is much better off.
420 - Move JSWebAssembly into the JS folder.
421 - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
422 - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
423 being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
424 stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
425 called wasm->JS stub. This move means that the embedder must, after creating
426 a Wasm::CodeBlock, somehow create the stubs to call back into the
427 embedder. This removes an indirection in the generated code because
428 the B3 IR generator now reaches into the instance instead of
429 JSWebAssemblyCodeBlock.
430 - Move more CodeBlock things. Compilation completion is now marked by its own
431 atomic<bool> flag instead of a nullptr plan: that required using a lock, and
432 was causing a deadlock in stack-trace.js because before my changes
433 JSWebAssemblyCodeBlock did its own completion checking separately from
434 Wasm::CodeBlock, without getting the lock. Now that everything points to
435 Wasm::CodeBlock and there's no cached completion marker, the lock was being
436 acquired in a sanity-check assertion.
437 - Embedder -> Wasm wrappers are now generated through a function that's passed
438 in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
439 - WasmMemory doens't need to know about fault handling thunks. Only the IR
440 generator should know, and should make sure that the exception throwing
441 thunk is generated if any memory is present (note: with signal handling not
442 all of them generate an exception check).
443 - Make exception throwing pluggable: instead of having a hard-coded
444 JS-specific lambda we now have a regular C++ function being called from JIT
445 code when a WebAssembly exception is thrown. This allows any embedder to get
446 called as they wish. For now a process can only have a single of these
447 functions (i.e. only one embedder per process) because the trap handler is a
448 singleton. That can be fixed in in #177475.
449 - Create WasmEmbedder.h where all embedder plugging will live.
450 - Split up JSWebAssemblyTable into Wasm::Table which is
451 refcounted. JSWebAssemblyTable now only contains the JS functions in the
452 table, and Wasm::Table is what's used by the JIT code to lookup where to
453 call and do the instance check (for context switch). Note that this creates
454 an extra allocation for all the instances in Wasm::Table, and in exchange
455 removes an indirection in JIT code because the instance used to be obtained
456 off of the JS function. Also note that it's the embedder than keeps the
457 instances alive, not Wasm::Table (which holds a dumb pointer to the
458 instance), because doing otherwise would cause reference cycles.
459 - Add WasmInstance. It doesn't do much for now, owns globals.
460 - JSWebAssembly instance now doesn't just contain the imported functions as
461 JSObjects, it also has the corresponding import's instance and wasm
462 entrypoint. This triples the space allocated per instance's imported
463 function, but there shouldn't be that many imports. This has two upsides: it
464 creates smaller and faster code, and makes is easier to disassociate
465 embedder-specific things from embedder-neutral things. The small / faster
466 win is in two places: B3 IR generator only needs offsetOfImportFunction for
467 the call opcode (when the called index is an import) to know whether the
468 import is wasm->wasm or wasm->embedder (this isn't known at compile-time
469 because it's dependent on the import object), this is now done by seeing if
470 that import function has an associated target instance (only wasm->wasm
471 does); the other place is wasmBinding which uses offsetOfImportFunction to
472 figure out the wasm->wasm target instance, and then gets
473 WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
474 call. The disassociation comes because the target instance can be
475 Wasm::Instance once we change what the Context is, and
476 WasmEntrypointLoadLocation is already embedder-independent. As a next step I
477 can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
478 and leave importFunction in as an opaque pointer which is embedder-specific,
479 and in JS will remain WriteBarrier<JSObject>.
480 - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
481 around instead of VM. This is a first step in allowing entry frames which
482 aren't stored on VM, but which are instead stored in an embedder-specific
483 location. That change won't really affect JS except through code churn, but
484 will allow WebAssembly to use some machinery in a generic manner without
487 * JavaScriptCore.xcodeproj/project.pbxproj:
489 * bytecode/PolymorphicAccess.cpp:
490 (JSC::AccessGenerationState::emitExplicitExceptionHandler):
491 * debugger/Debugger.cpp:
492 (JSC::Debugger::stepOutOfFunction):
493 (JSC::Debugger::returnEvent):
494 (JSC::Debugger::unwindEvent):
495 (JSC::Debugger::didExecuteProgram):
496 * dfg/DFGJITCompiler.cpp:
497 (JSC::DFG::JITCompiler::compileExceptionHandlers):
498 * dfg/DFGOSREntry.cpp:
499 (JSC::DFG::prepareOSREntry):
500 * dfg/DFGOSRExit.cpp:
501 (JSC::DFG::OSRExit::compileOSRExit):
502 (JSC::DFG::OSRExit::compileExit):
504 (JSC::DFG::osrEntryThunkGenerator):
505 * ftl/FTLCompile.cpp:
509 * ftl/FTLLowerDFGToB3.cpp:
510 (JSC::FTL::DFG::LowerDFGToB3::lower):
511 * ftl/FTLOSRExitCompiler.cpp:
512 (JSC::FTL::compileStub):
513 * interpreter/CallFrame.cpp:
514 (JSC::CallFrame::wasmAwareLexicalGlobalObject):
515 (JSC::CallFrame::callerFrame):
516 (JSC::CallFrame::unsafeCallerFrame):
517 * interpreter/CallFrame.h:
518 (JSC::ExecState::callerFrame const):
519 (JSC::ExecState::callerFrameOrEntryFrame const):
520 (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
521 * interpreter/FrameTracers.h:
522 (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
523 (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
524 (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
525 * interpreter/Interpreter.cpp:
526 (JSC::UnwindFunctor::operator() const):
527 (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
528 (JSC::Interpreter::unwind):
529 * interpreter/StackVisitor.cpp:
530 (JSC::StackVisitor::StackVisitor):
531 (JSC::StackVisitor::gotoNextFrame):
532 (JSC::StackVisitor::readNonInlinedFrame):
533 (JSC::StackVisitor::Frame::dump const):
534 * interpreter/StackVisitor.h:
535 (JSC::StackVisitor::Frame::callerIsEntryFrame const):
536 * interpreter/VMEntryRecord.h:
537 (JSC::VMEntryRecord::prevTopEntryFrame):
538 (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
539 (JSC::EntryFrame::vmEntryRecordOffset):
540 * jit/AssemblyHelpers.cpp:
541 (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
542 (JSC::AssemblyHelpers::loadWasmContextInstance):
543 (JSC::AssemblyHelpers::storeWasmContextInstance):
544 (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
545 (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
546 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
547 * jit/AssemblyHelpers.h:
548 (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
549 (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
550 (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
552 (JSC::JIT::emitEnterOptimizationCheck):
553 (JSC::JIT::privateCompileExceptionHandlers):
554 * jit/JITExceptions.cpp:
555 (JSC::genericUnwind):
556 * jit/JITOpcodes.cpp:
557 (JSC::JIT::emit_op_throw):
558 (JSC::JIT::emit_op_catch):
559 (JSC::JIT::emitSlow_op_loop_hint):
560 * jit/JITOpcodes32_64.cpp:
561 (JSC::JIT::emit_op_throw):
562 (JSC::JIT::emit_op_catch):
563 * jit/JITOperations.cpp:
564 * jit/ThunkGenerators.cpp:
565 (JSC::throwExceptionFromCallSlowPathGenerator):
566 (JSC::nativeForGenerator):
568 (functionDumpCallFrame):
569 * llint/LLIntSlowPaths.cpp:
570 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
571 * llint/LLIntThunks.cpp:
572 (JSC::vmEntryRecord):
573 * llint/LowLevelInterpreter.asm:
574 * llint/LowLevelInterpreter32_64.asm:
575 * llint/LowLevelInterpreter64.asm:
576 * runtime/Options.cpp:
577 (JSC::recomputeDependentOptions):
579 * runtime/SamplingProfiler.cpp:
580 (JSC::FrameWalker::FrameWalker):
581 (JSC::FrameWalker::advanceToParentFrame):
582 (JSC::SamplingProfiler::processUnverifiedStackTraces):
583 * runtime/ThrowScope.cpp:
584 (JSC::ThrowScope::~ThrowScope):
589 (JSC::VM::topEntryFrameOffset):
590 * runtime/VMTraps.cpp:
592 (JSC::VMTraps::tryInstallTrapBreakpoints):
593 (JSC::VMTraps::invalidateCodeBlocksOnStack):
594 * wasm/WasmB3IRGenerator.cpp:
595 (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
596 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
597 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
598 (JSC::Wasm::B3IRGenerator::addGrowMemory):
599 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
600 (JSC::Wasm::B3IRGenerator::addCall):
601 (JSC::Wasm::B3IRGenerator::addCallIndirect):
602 (JSC::Wasm::parseAndCompile):
603 * wasm/WasmB3IRGenerator.h:
604 * wasm/WasmBBQPlan.cpp:
605 (JSC::Wasm::BBQPlan::BBQPlan):
606 (JSC::Wasm::BBQPlan::compileFunctions):
607 (JSC::Wasm::BBQPlan::complete):
608 * wasm/WasmBBQPlan.h:
609 * wasm/WasmBBQPlanInlines.h:
610 (JSC::Wasm::BBQPlan::initializeCallees):
611 * wasm/WasmBinding.cpp:
612 (JSC::Wasm::wasmToWasm):
613 * wasm/WasmBinding.h:
614 * wasm/WasmCodeBlock.cpp:
615 (JSC::Wasm::CodeBlock::create):
616 (JSC::Wasm::CodeBlock::CodeBlock):
617 (JSC::Wasm::CodeBlock::compileAsync):
618 (JSC::Wasm::CodeBlock::setCompilationFinished):
619 * wasm/WasmCodeBlock.h:
620 (JSC::Wasm::CodeBlock::offsetOfImportStubs):
621 (JSC::Wasm::CodeBlock::allocationSize):
622 (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
623 (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
624 (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
625 (JSC::Wasm::CodeBlock::compilationFinished):
626 (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
627 (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
628 * wasm/WasmContext.cpp:
629 (JSC::Wasm::Context::useFastTLS):
630 (JSC::Wasm::Context::load const):
631 (JSC::Wasm::Context::store):
632 * wasm/WasmContext.h:
633 * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
634 * wasm/WasmFaultSignalHandler.cpp:
635 * wasm/WasmFaultSignalHandler.h:
637 * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
638 (JSC::Wasm::Instance::Instance):
639 (JSC::Wasm::Instance::~Instance):
640 (JSC::Wasm::Instance::extraMemoryAllocated const):
641 * wasm/WasmInstance.h: Added.
642 (JSC::Wasm::Instance::create):
643 (JSC::Wasm::Instance::finalizeCreation):
644 (JSC::Wasm::Instance::module):
645 (JSC::Wasm::Instance::codeBlock):
646 (JSC::Wasm::Instance::memory):
647 (JSC::Wasm::Instance::table):
648 (JSC::Wasm::Instance::loadI32Global const):
649 (JSC::Wasm::Instance::loadI64Global const):
650 (JSC::Wasm::Instance::loadF32Global const):
651 (JSC::Wasm::Instance::loadF64Global const):
652 (JSC::Wasm::Instance::setGlobal):
653 (JSC::Wasm::Instance::offsetOfCachedStackLimit):
654 (JSC::Wasm::Instance::cachedStackLimit const):
655 (JSC::Wasm::Instance::setCachedStackLimit):
656 * wasm/WasmMemory.cpp:
657 (JSC::Wasm::Memory::Memory):
658 (JSC::Wasm::Memory::create):
659 (JSC::Wasm::Memory::~Memory):
660 (JSC::Wasm::Memory::grow):
662 (JSC::Wasm::Memory::offsetOfMemory):
663 (JSC::Wasm::Memory::offsetOfSize):
664 * wasm/WasmMemoryInformation.cpp:
665 (JSC::Wasm::PinnedRegisterInfo::get):
666 (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
667 * wasm/WasmMemoryInformation.h:
668 (JSC::Wasm::PinnedRegisterInfo::toSave const):
669 * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
670 (JSC::Wasm::makeString):
671 * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
672 * wasm/WasmModule.cpp:
673 (JSC::Wasm::makeValidationCallback):
674 (JSC::Wasm::Module::validateSync):
675 (JSC::Wasm::Module::validateAsync):
676 (JSC::Wasm::Module::getOrCreateCodeBlock):
677 (JSC::Wasm::Module::compileSync):
678 (JSC::Wasm::Module::compileAsync):
680 * wasm/WasmModuleParser.cpp:
681 (JSC::Wasm::ModuleParser::parseTableHelper):
682 * wasm/WasmOMGPlan.cpp:
683 (JSC::Wasm::OMGPlan::OMGPlan):
684 (JSC::Wasm::OMGPlan::runForIndex):
685 * wasm/WasmOMGPlan.h:
686 * wasm/WasmPageCount.h:
687 (JSC::Wasm::PageCount::isValid const):
689 (JSC::Wasm::Plan::Plan):
690 (JSC::Wasm::Plan::runCompletionTasks):
691 (JSC::Wasm::Plan::addCompletionTask):
692 (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
694 (JSC::Wasm::Plan::dontFinalize):
695 * wasm/WasmSignature.cpp:
696 * wasm/WasmSignature.h:
697 * wasm/WasmTable.cpp: Added.
698 (JSC::Wasm::Table::create):
699 (JSC::Wasm::Table::~Table):
700 (JSC::Wasm::Table::Table):
701 (JSC::Wasm::Table::grow):
702 (JSC::Wasm::Table::clearFunction):
703 (JSC::Wasm::Table::setFunction):
704 * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
705 (JSC::Wasm::Table::maximum const):
706 (JSC::Wasm::Table::size const):
707 (JSC::Wasm::Table::offsetOfSize):
708 (JSC::Wasm::Table::offsetOfFunctions):
709 (JSC::Wasm::Table::offsetOfInstances):
710 (JSC::Wasm::Table::isValidSize):
711 * wasm/WasmThunks.cpp:
712 (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
713 (JSC::Wasm::triggerOMGTierUpThunkGenerator):
714 (JSC::Wasm::Thunks::setThrowWasmException):
715 (JSC::Wasm::Thunks::throwWasmException):
717 * wasm/WasmWorklist.cpp:
718 (JSC::Wasm::Worklist::stopAllPlansForContext):
719 * wasm/WasmWorklist.h:
720 * wasm/js/JSToWasm.cpp: Added.
721 (JSC::Wasm::createJSToWasmWrapper):
722 * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
723 * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
724 * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
725 * wasm/js/JSWebAssemblyCodeBlock.cpp:
726 (JSC::JSWebAssemblyCodeBlock::create):
727 (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
728 * wasm/js/JSWebAssemblyCodeBlock.h:
729 * wasm/js/JSWebAssemblyInstance.cpp:
730 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
731 (JSC::JSWebAssemblyInstance::finishCreation):
732 (JSC::JSWebAssemblyInstance::visitChildren):
733 (JSC::JSWebAssemblyInstance::finalizeCreation):
734 (JSC::JSWebAssemblyInstance::create):
735 * wasm/js/JSWebAssemblyInstance.h:
736 (JSC::JSWebAssemblyInstance::instance):
737 (JSC::JSWebAssemblyInstance::context const):
738 (JSC::JSWebAssemblyInstance::table):
739 (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
740 (JSC::JSWebAssemblyInstance::setMemory):
741 (JSC::JSWebAssemblyInstance::offsetOfTail):
742 (JSC::JSWebAssemblyInstance::importFunctionInfo):
743 (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
744 (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
745 (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
746 (JSC::JSWebAssemblyInstance::importFunction):
747 (JSC::JSWebAssemblyInstance::internalMemory):
748 (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
749 (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
750 (JSC::JSWebAssemblyInstance::offsetOfCallee):
751 (JSC::JSWebAssemblyInstance::offsetOfGlobals):
752 (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
753 (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
754 (JSC::JSWebAssemblyInstance::cachedStackLimit const):
755 (JSC::JSWebAssemblyInstance::setCachedStackLimit):
756 (JSC::JSWebAssemblyInstance::wasmMemory):
757 (JSC::JSWebAssemblyInstance::wasmModule):
758 (JSC::JSWebAssemblyInstance::allocationSize):
759 (JSC::JSWebAssemblyInstance::module const):
760 * wasm/js/JSWebAssemblyMemory.cpp:
761 (JSC::JSWebAssemblyMemory::create):
762 (JSC::JSWebAssemblyMemory::adopt):
763 (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
764 (JSC::JSWebAssemblyMemory::grow):
765 (JSC::JSWebAssemblyMemory::growSuccessCallback):
766 * wasm/js/JSWebAssemblyMemory.h:
767 * wasm/js/JSWebAssemblyModule.cpp:
768 (JSC::JSWebAssemblyModule::moduleInformation const):
769 (JSC::JSWebAssemblyModule::exportSymbolTable const):
770 (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
771 (JSC::JSWebAssemblyModule::callee const):
772 (JSC::JSWebAssemblyModule::codeBlock):
773 (JSC::JSWebAssemblyModule::module):
774 * wasm/js/JSWebAssemblyModule.h:
775 * wasm/js/JSWebAssemblyTable.cpp:
776 (JSC::JSWebAssemblyTable::create):
777 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
778 (JSC::JSWebAssemblyTable::visitChildren):
779 (JSC::JSWebAssemblyTable::grow):
780 (JSC::JSWebAssemblyTable::getFunction):
781 (JSC::JSWebAssemblyTable::clearFunction):
782 (JSC::JSWebAssemblyTable::setFunction):
783 * wasm/js/JSWebAssemblyTable.h:
784 (JSC::JSWebAssemblyTable::isValidSize):
785 (JSC::JSWebAssemblyTable::maximum const):
786 (JSC::JSWebAssemblyTable::size const):
787 (JSC::JSWebAssemblyTable::table):
788 * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
789 (JSC::Wasm::materializeImportJSCell):
790 (JSC::Wasm::wasmToJS):
791 (JSC::Wasm::wasmToJSException):
792 * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
793 * wasm/js/WebAssemblyFunction.cpp:
794 (JSC::callWebAssemblyFunction):
795 * wasm/js/WebAssemblyInstanceConstructor.cpp:
796 (JSC::constructJSWebAssemblyInstance):
797 * wasm/js/WebAssemblyMemoryConstructor.cpp:
798 (JSC::constructJSWebAssemblyMemory):
799 * wasm/js/WebAssemblyMemoryPrototype.cpp:
800 (JSC::webAssemblyMemoryProtoFuncGrow):
801 * wasm/js/WebAssemblyModuleConstructor.cpp:
802 (JSC::constructJSWebAssemblyModule):
803 (JSC::WebAssemblyModuleConstructor::createModule):
804 * wasm/js/WebAssemblyModuleConstructor.h:
805 * wasm/js/WebAssemblyModuleRecord.cpp:
806 (JSC::WebAssemblyModuleRecord::link):
807 (JSC::WebAssemblyModuleRecord::evaluate):
808 * wasm/js/WebAssemblyPrototype.cpp:
809 (JSC::webAssemblyCompileFunc):
811 (JSC::compileAndInstantiate):
812 (JSC::webAssemblyValidateFunc):
813 * wasm/js/WebAssemblyTableConstructor.cpp:
814 (JSC::constructJSWebAssemblyTable):
815 * wasm/js/WebAssemblyWrapperFunction.cpp:
816 (JSC::WebAssemblyWrapperFunction::create):
818 2017-10-19 Mark Lam <mark.lam@apple.com>
820 Stringifier::appendStringifiedValue() is missing an exception check.
821 https://bugs.webkit.org/show_bug.cgi?id=178386
822 <rdar://problem/35027610>
824 Reviewed by Saam Barati.
826 * runtime/JSONObject.cpp:
827 (JSC::Stringifier::appendStringifiedValue):
829 2017-10-19 Saam Barati <sbarati@apple.com>
831 REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
832 https://bugs.webkit.org/show_bug.cgi?id=178543
834 Reviewed by Filip Pizlo.
836 * dfg/DFGByteCodeParser.cpp:
837 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
839 2017-10-19 Saam Barati <sbarati@apple.com>
841 re-inline ObjectAllocationProfile::initializeProfile
842 https://bugs.webkit.org/show_bug.cgi?id=178532
844 Rubber stamped by Michael Saboff.
846 I un-inlined this function when implementing poly proto.
847 This patch re-inlines it. In my testing, it looks like it
848 might be a 0.5% speedometer progression to inline it.
850 * JavaScriptCore.xcodeproj/project.pbxproj:
852 * bytecode/CodeBlock.cpp:
853 * bytecode/ObjectAllocationProfile.cpp: Removed.
854 * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
855 (JSC::ObjectAllocationProfile::initializeProfile):
856 (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
857 * runtime/FunctionRareData.cpp:
859 2017-10-19 Michael Saboff <msaboff@apple.com>
861 Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
862 https://bugs.webkit.org/show_bug.cgi?id=178521
864 Reviewed by JF Bastien.
866 * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
867 standard version. The prior version was the draft 6.0 version.
869 2017-10-19 Saam Barati <sbarati@apple.com>
871 We should hard code the poly proto offset
872 https://bugs.webkit.org/show_bug.cgi?id=178531
874 Reviewed by Filip Pizlo.
876 This patch embraces that the poly proto offset is always zero. It's already
877 the case that we would always get the inline offset zero for poly proto just
878 by construction. This just hardcodes this assumption throughout the codebase.
879 This appears to be a 1% speedometer progression in my testing.
881 The downside of this patch is that it may require changing how we do
882 things when we implement poly proto when inheriting from builtin
883 types. I think we can face this problem when we decide to implement
886 * bytecode/AccessCase.cpp:
887 (JSC::AccessCase::generateWithGuard):
888 * dfg/DFGOperations.cpp:
889 * dfg/DFGSpeculativeJIT.cpp:
890 (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
891 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
892 * ftl/FTLLowerDFGToB3.cpp:
893 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
894 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
895 * jit/JITOpcodes.cpp:
896 (JSC::JIT::emit_op_instanceof):
897 * jit/JITOpcodes32_64.cpp:
898 (JSC::JIT::emit_op_instanceof):
899 * runtime/CommonSlowPaths.cpp:
900 (JSC::SLOW_PATH_DECL):
901 * runtime/JSObject.cpp:
902 (JSC::JSObject::setPrototypeDirect):
903 * runtime/JSObject.h:
904 (JSC::JSObject::locationForOffset const):
905 (JSC::JSObject::locationForOffset):
906 (JSC::JSObject::getDirect const):
907 * runtime/PropertyOffset.h:
908 * runtime/Structure.cpp:
909 (JSC::Structure::create):
910 (JSC::Structure::dump const):
911 * runtime/Structure.h:
912 * runtime/StructureInlines.h:
913 (JSC::Structure::storedPrototype const):
914 (JSC::Structure::storedPrototypeObject const):
916 2017-10-19 Saam Barati <sbarati@apple.com>
918 Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
919 https://bugs.webkit.org/show_bug.cgi?id=178529
921 Reviewed by Mark Lam.
923 * runtime/Structure.h:
924 * runtime/StructureInlines.h:
925 (JSC::Structure::storedPrototypeObject const):
926 (JSC::Structure::storedPrototypeStructure const):
927 (JSC::Structure::storedPrototype const):
928 (JSC::Structure::prototypeForLookup const):
929 (JSC::Structure::prototypeChain const):
931 2017-10-19 Saam Barati <sbarati@apple.com>
933 Turn poly proto back on by default and remove the option
934 https://bugs.webkit.org/show_bug.cgi?id=178525
936 Reviewed by Mark Lam.
938 I added this option because I thought it'd speed speedometer up because the
939 original poly proto patch slowed speedometer down. It turns out that
940 allocating poly proto objects is not what slows speedometer down. It's
941 other code I added in the runtime that needs to be poly proto aware. I'll
942 be addressing these in follow up patches.
945 * runtime/StructureInlines.h:
946 (JSC::Structure::shouldConvertToPolyProto):
948 2017-10-19 Robin Morisset <rmorisset@apple.com>
950 Turn recursive tail calls into loops
951 https://bugs.webkit.org/show_bug.cgi?id=176601
953 Reviewed by Saam Barati.
955 We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
956 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.
957 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.
958 We do this part through modifying the computation of the jump targets.
959 Importantly, we only do this splitting for functions that have tail calls.
960 It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
962 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.
963 The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
965 * bytecode/CodeBlock.h:
966 (JSC::CodeBlock::hasTailCalls const):
967 * bytecode/PreciseJumpTargets.cpp:
968 (JSC::getJumpTargetsForBytecodeOffset):
969 (JSC::computePreciseJumpTargetsInternal):
970 * bytecode/UnlinkedCodeBlock.cpp:
971 (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
972 * bytecode/UnlinkedCodeBlock.h:
973 (JSC::UnlinkedCodeBlock::hasTailCalls const):
974 (JSC::UnlinkedCodeBlock::setHasTailCalls):
975 * bytecompiler/BytecodeGenerator.cpp:
976 (JSC::BytecodeGenerator::emitEnter):
977 (JSC::BytecodeGenerator::emitCallInTailPosition):
978 * dfg/DFGByteCodeParser.cpp:
979 (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
980 (JSC::DFG::ByteCodeParser::makeBlockTargetable):
981 (JSC::DFG::ByteCodeParser::handleCall):
982 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
983 (JSC::DFG::ByteCodeParser::parseBlock):
984 (JSC::DFG::ByteCodeParser::parse):
986 2017-10-18 Mark Lam <mark.lam@apple.com>
988 RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
989 https://bugs.webkit.org/show_bug.cgi?id=177600
990 <rdar://problem/34710985>
992 Reviewed by Saam Barati.
994 According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
995 section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
996 descriptor value is present.
998 * runtime/RegExpObject.cpp:
999 (JSC::RegExpObject::defineOwnProperty):
1001 2017-10-18 Keith Miller <keith_miller@apple.com>
1003 Setup WebCore build to start using unified sources.
1004 https://bugs.webkit.org/show_bug.cgi?id=178362
1006 Reviewed by Tim Horton.
1008 Change comments in source list files. Also, pass explicit names for build files.
1011 * PlatformGTK.cmake:
1012 * PlatformMac.cmake:
1017 2017-10-18 Commit Queue <commit-queue@webkit.org>
1019 Unreviewed, rolling out r223321.
1020 https://bugs.webkit.org/show_bug.cgi?id=178476
1022 This protocol change broke some internal builds (Requested by
1023 brrian__ on #webkit).
1027 "Web Inspector: provide a way to enable/disable event
1029 https://bugs.webkit.org/show_bug.cgi?id=177451
1030 https://trac.webkit.org/changeset/223321
1032 2017-10-18 Mark Lam <mark.lam@apple.com>
1034 The compiler should always register a structure when it adds its transitionWatchPointSet.
1035 https://bugs.webkit.org/show_bug.cgi?id=178420
1036 <rdar://problem/34814024>
1038 Reviewed by Saam Barati and Filip Pizlo.
1040 Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
1041 now invoke Graph::registerAndWatchStructureTransition() on the structure.
1042 registerAndWatchStructureTransition() both registers the structure and add its
1043 transitionWatchpointSet to the plan desired watchpoints.
1045 Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
1046 except registerAndWatchStructureTransition() adds the structure's
1047 transitionWatchpointSet unconditionally.
1049 * dfg/DFGArgumentsEliminationPhase.cpp:
1050 * dfg/DFGArrayMode.cpp:
1051 (JSC::DFG::ArrayMode::refine const):
1052 * dfg/DFGByteCodeParser.cpp:
1053 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1054 * dfg/DFGFixupPhase.cpp:
1055 (JSC::DFG::FixupPhase::fixupNode):
1058 (JSC::DFG::Graph::registerAndWatchStructureTransition):
1061 * dfg/DFGSpeculativeJIT.cpp:
1062 (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1063 - The second set of addLazily()s is redundant. This set is executed only when
1064 prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
1065 only if we've executed the if statement above it. That preceding if statement
1066 already registerAndWatchStructureTransition() the same 2 structures. Hence,
1067 this second set can be deleted.
1069 * dfg/DFGWatchpointCollectionPhase.cpp:
1070 (JSC::DFG::WatchpointCollectionPhase::addLazily):
1071 - Deleted an unused function.
1073 * ftl/FTLLowerDFGToB3.cpp:
1074 (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
1076 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
1078 [JSC] Remove unused private name structure
1079 https://bugs.webkit.org/show_bug.cgi?id=178436
1081 Reviewed by Sam Weinig.
1083 It is no longer used. This patch just removes it.
1085 * runtime/JSGlobalObject.h:
1086 (JSC::JSGlobalObject::numberObjectStructure const):
1087 (JSC::JSGlobalObject::privateNameStructure const): Deleted.
1089 2017-10-18 Ryosuke Niwa <rniwa@webkit.org>
1091 Fix macOS and iOS builds after r223594.
1093 * JavaScriptCore.xcodeproj/project.pbxproj:
1095 2017-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
1097 [JSC] __proto__ getter should be fast
1098 https://bugs.webkit.org/show_bug.cgi?id=178067
1100 Reviewed by Saam Barati.
1102 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1103 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1104 Call node for this. It is inefficient since typically we know the `prototype` of the given
1105 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1106 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1107 we can still change this to efficient access to poly proto slot.
1109 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1110 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1111 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1112 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1113 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1116 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1118 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1119 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1120 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1122 This patch improves SixSpeed super.es6 by 3.42x.
1126 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
1128 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1130 * dfg/DFGAbstractInterpreterInlines.h:
1131 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1132 * dfg/DFGByteCodeParser.cpp:
1133 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1134 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1135 (JSC::DFG::ByteCodeParser::handleGetById):
1136 * dfg/DFGClobberize.h:
1137 (JSC::DFG::clobberize):
1138 * dfg/DFGDoesGC.cpp:
1140 * dfg/DFGFixupPhase.cpp:
1141 (JSC::DFG::FixupPhase::fixupNode):
1142 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1143 * dfg/DFGHeapLocation.cpp:
1144 (WTF::printInternal):
1145 * dfg/DFGHeapLocation.h:
1147 (JSC::DFG::Node::hasHeapPrediction):
1148 (JSC::DFG::Node::shouldSpeculateFunction):
1149 * dfg/DFGNodeType.h:
1150 * dfg/DFGOperations.cpp:
1151 * dfg/DFGOperations.h:
1152 * dfg/DFGPredictionPropagationPhase.cpp:
1153 * dfg/DFGSafeToExecute.h:
1154 (JSC::DFG::safeToExecute):
1155 * dfg/DFGSpeculativeJIT.cpp:
1156 (JSC::DFG::SpeculativeJIT::speculateFunction):
1157 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1158 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1159 * dfg/DFGSpeculativeJIT.h:
1160 (JSC::DFG::SpeculativeJIT::callOperation):
1161 * dfg/DFGSpeculativeJIT32_64.cpp:
1162 (JSC::DFG::SpeculativeJIT::compile):
1163 * dfg/DFGSpeculativeJIT64.cpp:
1164 (JSC::DFG::SpeculativeJIT::compile):
1165 * ftl/FTLCapabilities.cpp:
1166 (JSC::FTL::canCompile):
1167 * ftl/FTLLowerDFGToB3.cpp:
1168 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1169 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1170 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1171 * jit/IntrinsicEmitter.cpp:
1172 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1173 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1174 * jit/JITOperations.h:
1175 * runtime/Intrinsic.cpp:
1176 (JSC::intrinsicName):
1177 * runtime/Intrinsic.h:
1178 * runtime/JSGlobalObject.cpp:
1179 (JSC::JSGlobalObject::init):
1180 * runtime/JSGlobalObject.h:
1181 (JSC::JSGlobalObject::booleanPrototype const):
1182 (JSC::JSGlobalObject::numberPrototype const):
1183 (JSC::JSGlobalObject::booleanObjectStructure const):
1184 * runtime/JSGlobalObjectFunctions.cpp:
1185 (JSC::globalFuncProtoGetter):
1186 * runtime/JSGlobalObjectFunctions.h:
1187 * runtime/ObjectConstructor.cpp:
1188 * runtime/ReflectObject.cpp:
1190 2017-10-17 Ryan Haddad <ryanhaddad@apple.com>
1192 Unreviewed, rolling out r223523.
1194 A test for this change is failing on debug JSC bots.
1198 "[JSC] __proto__ getter should be fast"
1199 https://bugs.webkit.org/show_bug.cgi?id=178067
1200 https://trac.webkit.org/changeset/223523
1202 2017-10-17 Youenn Fablet <youenn@apple.com>
1204 Add preliminary support for fetch event
1205 https://bugs.webkit.org/show_bug.cgi?id=178171
1207 Reviewed by Chris Dumez.
1211 * runtime/JSPromise.h:
1213 2017-10-10 Yusuke Suzuki <utatane.tea@gmail.com>
1215 [JSC] __proto__ getter should be fast
1216 https://bugs.webkit.org/show_bug.cgi?id=178067
1218 Reviewed by Saam Barati.
1220 In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1221 Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1222 Call node for this. It is inefficient since typically we know the `prototype` of the given
1223 object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1224 If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1225 we can still change this to efficient access to poly proto slot.
1227 This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1228 the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1229 ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1230 constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1231 This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1234 And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1236 Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1237 poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1238 Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1240 This patch improves SixSpeed super.es6 by 3.42x.
1244 super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster
1246 [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1248 * dfg/DFGAbstractInterpreterInlines.h:
1249 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1250 * dfg/DFGByteCodeParser.cpp:
1251 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1252 (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1253 (JSC::DFG::ByteCodeParser::handleGetById):
1254 * dfg/DFGClobberize.h:
1255 (JSC::DFG::clobberize):
1256 * dfg/DFGDoesGC.cpp:
1258 * dfg/DFGFixupPhase.cpp:
1259 (JSC::DFG::FixupPhase::fixupNode):
1260 (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1261 * dfg/DFGHeapLocation.cpp:
1262 (WTF::printInternal):
1263 * dfg/DFGHeapLocation.h:
1265 (JSC::DFG::Node::hasHeapPrediction):
1266 (JSC::DFG::Node::shouldSpeculateFunction):
1267 * dfg/DFGNodeType.h:
1268 * dfg/DFGOperations.cpp:
1269 * dfg/DFGOperations.h:
1270 * dfg/DFGPredictionPropagationPhase.cpp:
1271 * dfg/DFGSafeToExecute.h:
1272 (JSC::DFG::safeToExecute):
1273 * dfg/DFGSpeculativeJIT.cpp:
1274 (JSC::DFG::SpeculativeJIT::speculateFunction):
1275 (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1276 (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1277 * dfg/DFGSpeculativeJIT.h:
1278 * dfg/DFGSpeculativeJIT32_64.cpp:
1279 (JSC::DFG::SpeculativeJIT::compile):
1280 * dfg/DFGSpeculativeJIT64.cpp:
1281 (JSC::DFG::SpeculativeJIT::compile):
1282 * ftl/FTLCapabilities.cpp:
1283 (JSC::FTL::canCompile):
1284 * ftl/FTLLowerDFGToB3.cpp:
1285 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1286 (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1287 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1288 * jit/IntrinsicEmitter.cpp:
1289 (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1290 (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1291 * runtime/Intrinsic.cpp:
1292 (JSC::intrinsicName):
1293 * runtime/Intrinsic.h:
1294 * runtime/JSGlobalObject.cpp:
1295 (JSC::JSGlobalObject::init):
1296 * runtime/JSGlobalObjectFunctions.cpp:
1297 (JSC::globalFuncProtoGetter):
1298 * runtime/JSGlobalObjectFunctions.h:
1299 * runtime/ObjectConstructor.cpp:
1300 * runtime/ReflectObject.cpp:
1302 2017-10-17 Keith Miller <keith_miller@apple.com>
1304 Change WebCore sources to work with unified source builds
1305 https://bugs.webkit.org/show_bug.cgi?id=178229
1307 Rubber stamped by Tim Horton.
1309 * Configurations/FeatureDefines.xcconfig:
1311 2017-10-15 Filip Pizlo <fpizlo@apple.com>
1313 Make some asserts into release asserts
1314 https://bugs.webkit.org/show_bug.cgi?id=178324
1316 Reviewed by Saam Barati.
1318 These asserts are not on perf critical paths, so they might as well be release asserts.
1320 * runtime/DataView.h:
1321 (JSC::DataView::get):
1322 (JSC::DataView::set):
1324 2017-10-16 JF Bastien <jfbastien@apple.com>
1326 JSRunLoopTimer: reduce likely race when used improperly
1327 https://bugs.webkit.org/show_bug.cgi?id=178298
1328 <rdar://problem/32899816>
1330 Reviewed by Saam Barati.
1332 If an API user sets a timer on JSRunLoopTimer, and then racily
1333 destroys the JSRunLoopTimer while the timer is firing then it's
1334 possible for timerDidFire to cause a use-after-free and / or crash
1335 because e.g. m_apiLock becomes a nullptr while timerDidFire is
1336 executing. That results from an invalid use of JSRunLoopTimer, but
1337 we should try to be more resilient for that type of misuse because
1338 it's not necessarily easy to catch by inspection.
1340 With this change the only remaining race is if the timer fires,
1341 and then only timerDidFire's prologue executes, but not the load
1342 of the m_apiLock pointer from `this`. It's a much smaller race.
1344 Separately, I'll reach out to API users who are seemingly misusing
1347 * runtime/JSRunLoopTimer.cpp:
1348 (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
1349 and checks for nullptr. This prevents loading it twice off of
1350 `this` and turns a nullptr deref into "just" a use-after-free.
1351 (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
1352 calling m_vm->unregisterRunLoopTimer(this), which in turn does
1353 CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
1354 timerDidFire from doing much while the timers are un-registered.
1355 ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
1356 releasing the lock, so it needs its own local copy.
1358 2017-10-15 Yusuke Suzuki <utatane.tea@gmail.com>
1360 [JSC] Perform module specifier validation at parsing time
1361 https://bugs.webkit.org/show_bug.cgi?id=178256
1363 Reviewed by Darin Adler.
1365 This patch make module loader's `resolve` operation synchronous. And we validate
1366 module's requested module names when instantiating the module instead of satisfying
1367 module's dependencies. This change is not observable to users. But this is precise
1368 to the spec and this optimizes & simplifies the current module loader a bit by
1369 reducing object allocations.
1371 Previously, we have an object called pair in the module loader. This is pair of
1372 module's name and module's record. And we use it to link one module to dependent
1373 modules. Now, it is replaced with module's registry entry.
1375 We also change our loader functions to take a registry entry instead of a module key.
1376 Previous design is due to the consideration that these APIs may be exposed to users
1377 in whatwg/loader spec. However, this won't happen. This change removes unnecessary
1378 repeatedly hash map lookups.
1380 * builtins/ModuleLoaderPrototype.js:
1381 (globalPrivate.newRegistryEntry):
1383 (requestInstantiate):
1389 (GlobalObject::moduleLoaderResolve):
1390 * runtime/AbstractModuleRecord.cpp:
1391 (JSC::AbstractModuleRecord::finishCreation):
1392 (JSC::AbstractModuleRecord::hostResolveImportedModule):
1393 * runtime/JSGlobalObject.h:
1394 * runtime/JSModuleLoader.cpp:
1395 (JSC::JSModuleLoader::resolveSync):
1396 (JSC::JSModuleLoader::resolve):
1397 * runtime/JSModuleLoader.h:
1398 * runtime/ModuleLoaderPrototype.cpp:
1399 (JSC::moduleLoaderPrototypeResolveSync):
1401 2017-10-14 Devin Rousso <webkit@devinrousso.com>
1403 Web Inspector: provide a way to enable/disable event listeners
1404 https://bugs.webkit.org/show_bug.cgi?id=177451
1406 Reviewed by Joseph Pecoraro.
1408 * inspector/protocol/DOM.json:
1409 Add `setEventListenerDisabled` command that enables/disables a specific event listener
1410 during event dispatch. When a disabled event listener is fired, the listener's callback will
1413 2017-10-14 Yusuke Suzuki <utatane.tea@gmail.com>
1415 Reland "Add Above/Below comparisons for UInt32 patterns"
1416 https://bugs.webkit.org/show_bug.cgi?id=177281
1418 Reviewed by Saam Barati.
1420 We reland this patch without DFGStrengthReduction change to see what causes
1421 regression in the iOS bot.
1423 Sometimes, we would like to have UInt32 operations in JS. While VM does
1424 not support UInt32 nicely, VM supports efficient Int32 operations. As long
1425 as signedness does not matter, we can just perform Int32 operations instead
1426 and recognize its bit pattern as UInt32.
1428 But of course, some operations respect signedness. The most frequently
1429 used one is comparison. Octane/zlib performs UInt32 comparison by performing
1430 `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
1431 UInt32 in Int32 form. And op_unsigned will generate Double value if
1432 the generated Int32 is < 0 (which should be UInt32).
1434 There is a chance for optimization. The given code pattern is the following.
1436 op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
1438 This can be converted to the following.
1440 op_urshift(@1) below:< op_urshift(@2)
1442 The above conversion is nice since
1444 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
1445 this check depends on the value of Int32, dropping this check is not as easy as
1446 removing Int32 edge filters.
1448 2. We can perform unsigned comparison in Int32 form. We do not need to convert
1451 Since the above comparison exists in Octane/zlib's *super* hot path, dropping
1452 op_unsigned offers huge win.
1454 At first, my patch attempts to convert the above thing in DFG pipeline.
1455 However it poses several problems.
1457 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
1458 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
1460 2: UInt32ToNumber(@0)
1462 4: UInt32ToNumber(@1)
1465 we could drop @5's MovHint. But @3 is difficult since @4 can exit.
1467 So, instead, we start introducing a simple optimization in the bytecode compiler.
1468 It performs pattern matching for op_urshift and comparison to drop op_unsigned.
1469 We adds op_below and op_above families to bytecodes. They only accept Int32 and
1470 perform unsigned comparison.
1472 This offers 4% performance improvement in Octane/zlib.
1476 zlib x2 431.07483+-16.28434 414.33407+-9.38375 might be 1.0404x faster
1478 * bytecode/BytecodeDumper.cpp:
1479 (JSC::BytecodeDumper<Block>::printCompareJump):
1480 (JSC::BytecodeDumper<Block>::dumpBytecode):
1481 * bytecode/BytecodeDumper.h:
1482 * bytecode/BytecodeList.json:
1483 * bytecode/BytecodeUseDef.h:
1484 (JSC::computeUsesForBytecodeOffset):
1485 (JSC::computeDefsForBytecodeOffset):
1486 * bytecode/Opcode.h:
1488 * bytecode/PreciseJumpTargetsInlines.h:
1489 (JSC::extractStoredJumpTargetsForBytecodeOffset):
1490 * bytecompiler/BytecodeGenerator.cpp:
1491 (JSC::BytecodeGenerator::emitJumpIfTrue):
1492 (JSC::BytecodeGenerator::emitJumpIfFalse):
1493 * bytecompiler/NodesCodegen.cpp:
1494 (JSC::BinaryOpNode::emitBytecode):
1495 * dfg/DFGAbstractInterpreterInlines.h:
1496 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1497 * dfg/DFGByteCodeParser.cpp:
1498 (JSC::DFG::ByteCodeParser::parseBlock):
1499 * dfg/DFGCapabilities.cpp:
1500 (JSC::DFG::capabilityLevel):
1501 * dfg/DFGClobberize.h:
1502 (JSC::DFG::clobberize):
1503 * dfg/DFGDoesGC.cpp:
1505 * dfg/DFGFixupPhase.cpp:
1506 (JSC::DFG::FixupPhase::fixupNode):
1507 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1508 * dfg/DFGNodeType.h:
1509 * dfg/DFGPredictionPropagationPhase.cpp:
1510 * dfg/DFGSafeToExecute.h:
1511 (JSC::DFG::safeToExecute):
1512 * dfg/DFGSpeculativeJIT.cpp:
1513 (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
1514 * dfg/DFGSpeculativeJIT.h:
1515 * dfg/DFGSpeculativeJIT32_64.cpp:
1516 (JSC::DFG::SpeculativeJIT::compile):
1517 * dfg/DFGSpeculativeJIT64.cpp:
1518 (JSC::DFG::SpeculativeJIT::compile):
1519 * dfg/DFGValidate.cpp:
1520 * ftl/FTLCapabilities.cpp:
1521 (JSC::FTL::canCompile):
1522 * ftl/FTLLowerDFGToB3.cpp:
1523 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1524 (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
1525 (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
1527 (JSC::JIT::privateCompileMainPass):
1529 * jit/JITArithmetic.cpp:
1530 (JSC::JIT::emit_op_below):
1531 (JSC::JIT::emit_op_beloweq):
1532 (JSC::JIT::emit_op_jbelow):
1533 (JSC::JIT::emit_op_jbeloweq):
1534 (JSC::JIT::emit_compareUnsignedAndJump):
1535 (JSC::JIT::emit_compareUnsigned):
1536 * jit/JITArithmetic32_64.cpp:
1537 (JSC::JIT::emit_compareUnsignedAndJump):
1538 (JSC::JIT::emit_compareUnsigned):
1539 * llint/LowLevelInterpreter.asm:
1540 * llint/LowLevelInterpreter32_64.asm:
1541 * llint/LowLevelInterpreter64.asm:
1543 (JSC::ExpressionNode::isBinaryOpNode const):
1545 2017-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
1547 WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
1548 https://bugs.webkit.org/show_bug.cgi?id=178210
1550 Reviewed by Saam Barati.
1552 In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
1553 The former is an exported wasm function and the latter is an imported & exported function. Since they
1554 have [[Call]], they should be categorized into "function" in typeof operation.
1556 However, these functions do not implement our function protocol correctly. They inherit JSFunction.
1557 But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
1558 ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
1561 In this patch, we address the above issue by the following 2 fixes.
1563 1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
1564 InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
1565 implementation, we cannot make this JSFunctionType.
1567 2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
1568 changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
1569 classes of JSFunction (e.g. JSCustomGetterSetterFunction).
1571 * wasm/js/WebAssemblyFunction.h:
1572 (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
1573 (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
1574 (JSC::WebAssemblyFunction::callableFunction const): Deleted.
1575 (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
1576 (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
1577 * wasm/js/WebAssemblyWrapperFunction.cpp:
1578 (JSC::WebAssemblyWrapperFunction::createStructure):
1579 * wasm/js/WebAssemblyWrapperFunction.h:
1580 (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
1581 (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
1582 (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
1583 (JSC::WebAssemblyWrapperFunction::function): Deleted.
1585 2017-10-12 Per Arne Vollan <pvollan@apple.com>
1587 [Win64] JSC compile error.
1588 https://bugs.webkit.org/show_bug.cgi?id=178213
1590 Reviewed by Alex Christensen.
1592 Add static cast from int64 to uintptr_t.
1594 * dfg/DFGOSRExit.cpp:
1595 (JSC::DFG::OSRExit::executeOSRExit):
1597 2017-09-29 Filip Pizlo <fpizlo@apple.com>
1599 Enable gigacage on iOS
1600 https://bugs.webkit.org/show_bug.cgi?id=177586
1602 Reviewed by JF Bastien.
1604 The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
1605 executing JS, so the LLInt needs to know how to load from global variables on all platforms that
1606 have Gigacage. So, this teaches ARM64 how to load from global variables.
1608 Also, this makes the code handle disabling the gigacage a bit better.
1610 * ftl/FTLLowerDFGToB3.cpp:
1611 (JSC::FTL::DFG::LowerDFGToB3::caged):
1612 * jit/AssemblyHelpers.h:
1613 (JSC::AssemblyHelpers::cage):
1614 (JSC::AssemblyHelpers::cageConditionally):
1615 * offlineasm/arm64.rb:
1616 * offlineasm/asm.rb:
1617 * offlineasm/instructions.rb:
1619 2017-10-11 Sam Weinig <sam@webkit.org>
1621 Remove out-parameter variants of copyToVector
1622 https://bugs.webkit.org/show_bug.cgi?id=178155
1624 Reviewed by Tim Horton.
1626 * inspector/ScriptDebugServer.cpp:
1627 (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
1628 (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
1629 (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
1630 (Inspector::ScriptDebugServer::dispatchDidParseSource):
1631 (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
1632 (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
1634 Replace out-parameter based copyToVector, with one that returns a Vector.
1636 2017-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
1638 Support integrity="" on module scripts
1639 https://bugs.webkit.org/show_bug.cgi?id=177959
1641 Reviewed by Sam Weinig.
1643 This patch adds Subresource Integrity check for module scripts. Currently,
1644 only top-level module can be verified with integrity parameter since there
1645 is no way to perform integrity check onto the imported modules.
1647 In JSC side, we add `parameters` to the entry point of the module loader
1648 pipeline. This is fetching parameters and used when fetching modules.
1650 We separately pass this parameters to the pipeline along with the script fetcher.
1651 The script fetcher is only one for module graph since this is the initiator of
1652 this module graph loading. On the other hand, this parameters is for each
1653 module fetching. While setting "integrity" parameters to this script fetcher is
1654 sufficient to pass parameters to top-level-module's fetching, it is not enough
1655 for the future extension.
1657 In the future, we will investigate a way to pass parameters to each non-top-level
1658 module. At that time, this `parameters` should be per-module. This is because
1659 "integrity" value should be different for each module. For example, we will accept
1660 some form of syntax to add parameters to `import`. Some proposed syntax is like
1661 https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
1663 import "./xxx.js" integrity "xxxxxxx"
1665 In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
1666 `parameters` should be different from the one of top-level-module's one. That's why
1667 we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
1669 On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
1670 is important to offer module-graph-wide information. For example, import.meta would
1671 have `import.meta.scriptElement`, which is the script element fetching the module graph
1672 including this. So, we keep the both, script fetcher and parameters.
1673 https://github.com/tc39/proposal-import-meta
1675 This parameters will be finally used by pipeline's fetch hook, and WebCore side
1676 can use this parameters to fetch modules.
1678 We also further clean up the module pipeline by dropping unnecessary features.
1680 * JavaScriptCore.xcodeproj/project.pbxproj:
1682 * builtins/ModuleLoaderPrototype.js:
1684 (requestInstantiate):
1687 (loadAndEvaluateModule):
1688 This loadAndEvaluateModule should be implemented by just calling loadModule and
1689 linkAndEvaluateModule. We can drop requestReady and requestLink.
1691 (requestLink): Deleted.
1692 (requestImportModule): Deleted.
1694 (GlobalObject::moduleLoaderImportModule):
1695 (GlobalObject::moduleLoaderFetch):
1696 import and fetch hook takes parameters. Currently, we always pass `undefined` for
1697 import hook. When dynamic `import()` is extended to accept additional parameters
1698 like integrity, this parameters will be replaced with the actual value.
1700 (functionLoadModule):
1702 * runtime/Completion.cpp:
1703 (JSC::loadAndEvaluateModule):
1705 (JSC::importModule):
1706 * runtime/Completion.h:
1707 * runtime/JSGlobalObject.h:
1708 * runtime/JSGlobalObjectFunctions.cpp:
1709 (JSC::globalFuncImportModule):
1710 * runtime/JSModuleLoader.cpp:
1711 (JSC::JSModuleLoader::loadAndEvaluateModule):
1712 (JSC::JSModuleLoader::loadModule):
1713 (JSC::JSModuleLoader::requestImportModule):
1714 (JSC::JSModuleLoader::importModule):
1715 (JSC::JSModuleLoader::fetch):
1716 * runtime/JSModuleLoader.h:
1717 * runtime/JSScriptFetchParameters.cpp: Added.
1718 (JSC::JSScriptFetchParameters::destroy):
1719 * runtime/JSScriptFetchParameters.h: Added.
1720 (JSC::JSScriptFetchParameters::createStructure):
1721 (JSC::JSScriptFetchParameters::create):
1722 (JSC::JSScriptFetchParameters::parameters const):
1723 (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
1724 Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
1725 It is used in the module pipeline.
1728 * runtime/ModuleLoaderPrototype.cpp:
1729 (JSC::moduleLoaderPrototypeFetch):
1730 * runtime/ScriptFetchParameters.h: Added.
1731 (JSC::ScriptFetchParameters::~ScriptFetchParameters):
1732 Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
1733 by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
1740 2017-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
1742 import.meta should not be assignable
1743 https://bugs.webkit.org/show_bug.cgi?id=178202
1745 Reviewed by Saam Barati.
1747 `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
1748 and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
1749 We change the parser not to allow assignments for MetaPropertyNode.
1751 * bytecompiler/NodesCodegen.cpp:
1752 (JSC::ImportMetaNode::emitBytecode):
1753 * parser/ASTBuilder.h:
1754 (JSC::ASTBuilder::createImportMetaExpr):
1755 (JSC::ASTBuilder::isMetaProperty):
1756 (JSC::ASTBuilder::isImportMeta):
1757 * parser/NodeConstructors.h:
1758 (JSC::MetaPropertyNode::MetaPropertyNode):
1759 (JSC::NewTargetNode::NewTargetNode):
1760 (JSC::ImportMetaNode::ImportMetaNode):
1762 (JSC::ExpressionNode::isMetaProperty const):
1763 (JSC::ExpressionNode::isImportMeta const):
1764 * parser/Parser.cpp:
1765 (JSC::Parser<LexerType>::metaPropertyName):
1766 (JSC::Parser<LexerType>::parseAssignmentExpression):
1767 (JSC::Parser<LexerType>::parseMemberExpression):
1768 (JSC::Parser<LexerType>::parseUnaryExpression):
1770 * parser/SyntaxChecker.h:
1771 (JSC::SyntaxChecker::createImportMetaExpr):
1772 (JSC::SyntaxChecker::isMetaProperty):
1773 (JSC::SyntaxChecker::isImportMeta):
1775 2017-10-11 Saam Barati <sbarati@apple.com>
1777 Runtime disable poly proto because it may be a 3-4% Speedometer regression
1778 https://bugs.webkit.org/show_bug.cgi?id=178192
1780 Reviewed by JF Bastien.
1782 * runtime/Options.h:
1783 * runtime/StructureInlines.h:
1784 (JSC::Structure::shouldConvertToPolyProto):
1786 2017-10-11 Commit Queue <commit-queue@webkit.org>
1788 Unreviewed, rolling out r223113 and r223121.
1789 https://bugs.webkit.org/show_bug.cgi?id=178182
1791 Reintroduced 20% regression on Kraken (Requested by rniwa on
1794 Reverted changesets:
1796 "Enable gigacage on iOS"
1797 https://bugs.webkit.org/show_bug.cgi?id=177586
1798 https://trac.webkit.org/changeset/223113
1800 "Use one virtual allocation for all gigacages and their
1802 https://bugs.webkit.org/show_bug.cgi?id=178050
1803 https://trac.webkit.org/changeset/223121
1805 2017-10-11 Michael Saboff <msaboff@apple.com>
1807 Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
1808 https://bugs.webkit.org/show_bug.cgi?id=178106
1810 Reviewed by Keith Miller.
1812 * ucd/CaseFolding.txt:
1814 2017-10-11 Caio Lima <ticaiolima@gmail.com>
1816 Object properties are undefined in super.call() but not in this.call()
1817 https://bugs.webkit.org/show_bug.cgi?id=177230
1819 Reviewed by Saam Barati.
1821 Bytecode generation for "super.call(...)" or "super.apply(...)"
1822 shouldn't be considered as CallFunctionCallDotNode or
1823 ApplyFunctionCallDotNode because they should be considered as common
1824 super property access as any other function. According to spec[1],
1825 "super" is not refering to parent constructor.
1827 [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
1829 * parser/ASTBuilder.h:
1830 (JSC::ASTBuilder::makeFunctionCallNode):
1831 * parser/Parser.cpp:
1832 (JSC::Parser<LexerType>::parseMemberExpression):
1833 * parser/SyntaxChecker.h:
1834 (JSC::SyntaxChecker::makeFunctionCallNode):
1836 2017-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
1838 [JSC] Drop Instantiate hook in ES6 module loader
1839 https://bugs.webkit.org/show_bug.cgi?id=178162
1841 Reviewed by Sam Weinig.
1843 This patch is a part of patch series for module loader refactoring to adopt
1844 integrity="" parameters and introduce new whatwg module import mechanism.
1846 In this patch, we drop instantiate hook in module loader. This hook is originally
1847 introduced because it is defined in whatwg/loader spec. But this hook is not
1848 used in our implementation, and this hook won't be used since (1) whatwg/loader
1849 spec is abandoned, and (2) this type of hooks should be done in Service Workers.
1851 In addition, this patch applies some cleaning up of our module loader JS code
1852 to simplify things. This change paves the way to more efficient loader implementation
1853 with great flexibility to adopt integrity="" parameters.
1855 * builtins/ModuleLoaderPrototype.js:
1856 (requestInstantiate):
1858 provide is changed to provideFetch since we only used this function with Fetch stage parameter.
1860 (fulfillInstantiate): Deleted.
1861 (commitInstantiated): Deleted.
1862 (instantiation): Deleted.
1863 They are merged into requestInstantiate code. This is simpler.
1867 * runtime/Completion.cpp:
1868 (JSC::loadAndEvaluateModule):
1870 * runtime/JSGlobalObject.cpp:
1871 * runtime/JSGlobalObject.h:
1872 * runtime/JSModuleLoader.cpp:
1873 (JSC::JSModuleLoader::provideFetch):
1874 (JSC::JSModuleLoader::provide): Deleted.
1875 Changed to provideFetch.
1877 (JSC::JSModuleLoader::instantiate): Deleted.
1880 * runtime/JSModuleLoader.h:
1881 * runtime/ModuleLoaderPrototype.cpp:
1882 (JSC::moduleLoaderPrototypeInstantiate): Deleted.
1885 2017-10-10 Saam Barati <sbarati@apple.com>
1887 Prototype structure transition should be a deferred transition
1888 https://bugs.webkit.org/show_bug.cgi?id=177734
1890 Reviewed by Keith Miller.
1892 Absence ObjectPropertyConditions work by verifying both that the Structure
1893 does not have a particular property and that its prototype has
1894 remained constant. However, the prototype transition was firing
1895 the transition watchpoint before setting the object's structure.
1896 This meant that isValid for Absence would never return false because
1897 the prototype changed. Clearly this is wrong. The reason this didn't
1898 break OPCs in general is that we'd also check if we could still watch
1899 the OPC. In this case, we can't still watch it because we're inspecting
1900 a structure with an invalidated transition watchpoint. To fix
1901 this weird quirk of the code, I'm making it so that doing a prototype
1902 transition uses the DeferredStructureTransitionWatchpointFire machinery.
1904 This patch also fixes some dead code that I left in regarding
1907 * bytecode/PropertyCondition.cpp:
1908 (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
1909 * runtime/JSObject.cpp:
1910 (JSC::JSObject::setPrototypeDirect):
1911 * runtime/Structure.cpp:
1912 (JSC::Structure::changePrototypeTransition):
1913 * runtime/Structure.h:
1915 2017-10-10 Robin Morisset <rmorisset@apple.com>
1917 Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
1918 https://bugs.webkit.org/show_bug.cgi?id=177926
1920 Reviewed by Saam Barati.
1922 When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
1923 With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
1924 The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
1926 * dfg/DFGByteCodeParser.cpp:
1927 (JSC::DFG::ByteCodeParser::inlineCall):
1928 (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1929 (JSC::DFG::ByteCodeParser::handleInlining):
1930 (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1931 (JSC::DFG::ByteCodeParser::parse):
1933 2017-10-10 Guillaume Emont <guijemont@igalia.com>
1935 Fix compilation when MASM_PROBE (and therefore DFG) are disabled
1936 https://bugs.webkit.org/show_bug.cgi?id=178134
1938 Reviewed by Saam Barati.
1940 * bytecode/CodeBlock.cpp:
1941 * bytecode/CodeBlock.h:
1942 Disable some code when building without DFG_JIT.
1944 2017-10-10 Sam Weinig <sam@webkit.org>
1946 Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
1947 https://bugs.webkit.org/show_bug.cgi?id=178102
1949 Reviewed by Tim Horton.
1951 * inspector/agents/InspectorDebuggerAgent.cpp:
1952 (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
1954 2017-10-10 Michael Saboff <msaboff@apple.com>
1956 Unreviewed build fix.
1958 Removed unused lambda capture.
1960 * yarr/YarrPattern.cpp:
1961 (JSC::Yarr::CharacterClassConstructor::appendInverted):
1963 2017-10-10 Saam Barati <sbarati@apple.com>
1965 The prototype cache should be aware of the Executable it generates a Structure for
1966 https://bugs.webkit.org/show_bug.cgi?id=177907
1968 Reviewed by Filip Pizlo.
1970 This patch renames PrototypeMap to StructureCache because
1971 it is no longer a map of the prototypes in the VM. It's
1972 only used to cache Structures during object construction.
1974 The main change of this patch is to guarantee that Structures generated
1975 by the create_this originating from different two different Executables'
1976 bytecode won't hash-cons to the same thing. Previously, we could hash-cons
1977 them depending on the JSObject* prototype pointer. This would cause the last
1978 thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
1979 happened because when we initialize a JSFunction's ObjectAllocationProfile,
1980 we set the resulting Structure's poly proto watchpoint. This could cause a Structure
1981 generating from some Executable e1 to end up with the poly proto watchpoint
1982 for another Executable e2 simply because JSFunctions backed by e1 and e2
1983 shared the same prototype. Then, based on profiling information, we may fire the
1984 wrong Executable's poly proto watchpoint. This patch fixes this bug by
1985 guaranteeing that Structures generating from create_this for different
1986 Executables are unique even if they share the same prototype by adding
1987 the FunctionExecutable* as another field in PrototypeKey.
1989 * JavaScriptCore.xcodeproj/project.pbxproj:
1991 * bytecode/InternalFunctionAllocationProfile.h:
1992 (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
1993 * bytecode/ObjectAllocationProfile.cpp:
1994 (JSC::ObjectAllocationProfile::initializeProfile):
1995 * dfg/DFGOperations.cpp:
1996 * runtime/CommonSlowPaths.cpp:
1997 (JSC::SLOW_PATH_DECL):
1998 * runtime/InternalFunction.cpp:
1999 (JSC::InternalFunction::createSubclassStructureSlow):
2000 * runtime/IteratorOperations.cpp:
2001 (JSC::createIteratorResultObjectStructure):
2002 * runtime/JSBoundFunction.cpp:
2003 (JSC::getBoundFunctionStructure):
2004 * runtime/JSGlobalObject.cpp:
2005 (JSC::JSGlobalObject::init):
2006 * runtime/ObjectConstructor.h:
2007 (JSC::constructEmptyObject):
2008 * runtime/PrototypeKey.h:
2009 (JSC::PrototypeKey::PrototypeKey):
2010 (JSC::PrototypeKey::executable const):
2011 (JSC::PrototypeKey::operator== const):
2012 (JSC::PrototypeKey::hash const):
2013 * runtime/PrototypeMap.cpp: Removed.
2014 * runtime/PrototypeMap.h: Removed.
2015 * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
2016 (JSC::StructureCache::createEmptyStructure):
2017 (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
2018 (JSC::StructureCache::emptyObjectStructureForPrototype):
2019 (JSC::PrototypeMap::createEmptyStructure): Deleted.
2020 (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
2021 (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
2022 * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
2023 (JSC::StructureCache::StructureCache):
2024 (JSC::PrototypeMap::PrototypeMap): Deleted.
2029 2017-10-09 Yusuke Suzuki <utatane.tea@gmail.com>
2031 `async` should be able to be used as an imported binding name
2032 https://bugs.webkit.org/show_bug.cgi?id=176573
2034 Reviewed by Saam Barati.
2036 Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2037 and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2038 since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2039 For example, import declaration failed to bind imported binding to the name "async" because
2040 the parser considered ASYNC as keyword.
2042 This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2043 the current performance without using this ASYNC keyword.
2045 We also add `escaped` field to token data since contextual keyword is valid only if it does
2046 not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
2047 e.g. `of in for-of`. This improves test262 score.
2049 * parser/Keywords.table:
2051 (JSC::Lexer<LChar>::parseIdentifier):
2052 (JSC::Lexer<UChar>::parseIdentifier):
2053 (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2054 * parser/Parser.cpp:
2055 (JSC::Parser<LexerType>::parseStatementListItem):
2056 (JSC::Parser<LexerType>::parseForStatement):
2057 (JSC::Parser<LexerType>::parseStatement):
2058 (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2059 (JSC::Parser<LexerType>::parseClass):
2060 (JSC::Parser<LexerType>::parseExportDeclaration):
2061 (JSC::Parser<LexerType>::parseAssignmentExpression):
2062 (JSC::Parser<LexerType>::parseProperty):
2063 (JSC::Parser<LexerType>::parsePrimaryExpression):
2064 (JSC::Parser<LexerType>::parseMemberExpression):
2065 (JSC::Parser<LexerType>::printUnexpectedTokenText):
2067 (JSC::Parser::matchContextualKeyword):
2068 * parser/ParserTokens.h:
2069 * runtime/CommonIdentifiers.h:
2071 2017-10-09 Saam Barati <sbarati@apple.com>
2073 We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
2074 https://bugs.webkit.org/show_bug.cgi?id=177987
2076 Reviewed by Filip Pizlo.
2078 * runtime/JSProxy.cpp:
2079 (JSC::JSProxy::setTarget):
2080 * runtime/PrototypeMap.cpp:
2081 (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
2082 * runtime/PrototypeMap.h:
2084 2017-10-09 Filip Pizlo <fpizlo@apple.com>
2086 JSCell::didBecomePrototype is racy
2087 https://bugs.webkit.org/show_bug.cgi?id=178110
2089 Reviewed by Saam Barati.
2091 The indexing type can be modified by any thread using CAS. So, we need to use atomics when
2092 modifying it. We don't need to use atomics when reading it though (since it's just one field).
2094 * runtime/JSCellInlines.h:
2095 (JSC::JSCell::didBecomePrototype):
2097 2017-09-29 Filip Pizlo <fpizlo@apple.com>
2099 Enable gigacage on iOS
2100 https://bugs.webkit.org/show_bug.cgi?id=177586
2102 Reviewed by JF Bastien.
2104 The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2105 executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2106 have Gigacage. So, this teaches ARM64 how to load from global variables.
2108 Also, this makes the code handle disabling the gigacage a bit better.
2110 * ftl/FTLLowerDFGToB3.cpp:
2111 (JSC::FTL::DFG::LowerDFGToB3::caged):
2112 * jit/AssemblyHelpers.h:
2113 (JSC::AssemblyHelpers::cage):
2114 (JSC::AssemblyHelpers::cageConditionally):
2115 * offlineasm/arm64.rb:
2116 * offlineasm/asm.rb:
2117 * offlineasm/instructions.rb:
2119 2017-10-09 Robin Morisset <rmorisset@apple.com>
2121 Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
2122 https://bugs.webkit.org/show_bug.cgi?id=177925
2124 Reviewed by Saam Barati.
2126 We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
2127 the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
2128 that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).
2130 * dfg/DFGByteCodeParser.cpp:
2131 (JSC::DFG::ByteCodeParser::parseBlock):
2132 (JSC::DFG::ByteCodeParser::parseCodeBlock):
2134 2017-10-09 Robin Morisset <rmorisset@apple.com>
2136 Refactor the inliner to simplify block linking
2137 https://bugs.webkit.org/show_bug.cgi?id=177922
2139 Reviewed by Saam Barati.
2141 The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
2142 some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
2143 - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
2144 - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
2145 Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
2146 This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
2147 or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
2148 terminal that needs to be taken off m_unlinkedBlocks.
2149 I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
2150 that is the one that holds their target in its m_linkingTargets field.
2152 There are a few much smaller refactors in this patch:
2153 - parse() is now of type void insted of bool (it was always returning true)
2154 - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
2155 - The 9 argument version was cleaned up and simplified
2156 - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
2157 - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
2158 - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
2160 * dfg/DFGByteCodeParser.cpp:
2161 (JSC::DFG::ByteCodeParser::addToGraph):
2162 (JSC::DFG::ByteCodeParser::handleCall):
2163 (JSC::DFG::ByteCodeParser::refineStatically):
2164 (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2165 (JSC::DFG::ByteCodeParser::handleVarargsCall):
2166 (JSC::DFG::ByteCodeParser::inlineCall):
2167 (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2168 (JSC::DFG::ByteCodeParser::handleInlining):
2169 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2170 (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2171 (JSC::DFG::ByteCodeParser::parseBlock):
2172 (JSC::DFG::ByteCodeParser::parseCodeBlock):
2173 (JSC::DFG::ByteCodeParser::parse):
2175 (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
2176 * dfg/DFGByteCodeParser.h:
2178 (JSC::DFG::Plan::compileInThreadImpl):
2180 2017-10-09 Michael Saboff <msaboff@apple.com>
2182 Implement RegExp Unicode property escapes
2183 https://bugs.webkit.org/show_bug.cgi?id=172069
2185 Reviewed by JF Bastien.
2187 Added Unicode Properties by extending the existing CharacterClass processing.
2189 Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
2190 Unicode Database files to create character class data. The result is a set of functions
2191 that return character classes, one for each of the required Unicode properties.
2192 There are many cases where many properties are handled by one function, primarily due to
2193 property aliases, but also due to Script_Extension properties that are the same as the
2194 Script property for the same script value.
2196 Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
2197 character classes. Unicode properties are the enum value BaseUnicodePropertyID plus a
2198 zero based value, that value being the index to the corrensponding character class
2199 function. The generation script also creates static hashing tables similar to what we
2200 use for the generated .lut.h lookup table files. These hashing tables map property
2201 names to the function index. Using these hashing tables, we can lookup a property
2202 name and if present convert it to a function index. We add that index to
2203 BaseUnicodePropertyID to create a BuiltInCharacterClassID.
2205 When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
2206 When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
2207 the actual character class by calling the corresponding generated function.
2209 Added a new CharacterClass constructor that can take literal arrays for ranges and matches
2210 to make the creation of large static character classes more efficent.
2212 Since the Unicode character classes typically have more matches and ranges, the character
2213 class matching in the interpreter has been updated to use binary searching for matches and
2214 ranges with more than 6 entries.
2217 * DerivedSources.make:
2218 * JavaScriptCore.xcodeproj/project.pbxproj:
2219 * Scripts/generateYarrUnicodePropertyTables.py: Added.
2221 (openUCDFileOrExit):
2222 (verifyUCDFilesExist):
2223 (ceilingToPowerOf2):
2226 (Aliases.parsePropertyAliasesFile):
2227 (Aliases.parsePropertyValueAliasesFile):
2228 (Aliases.globalAliasesFor):
2229 (Aliases.generalCategoryAliasesFor):
2230 (Aliases.generalCategoryForAlias):
2231 (Aliases.scriptAliasesFor):
2232 (Aliases.scriptNameForAlias):
2234 (PropertyData.__init__):
2235 (PropertyData.setAliases):
2236 (PropertyData.makeCopy):
2237 (PropertyData.getIndex):
2238 (PropertyData.getCreateFuncName):
2239 (PropertyData.addMatch):
2240 (PropertyData.addRange):
2241 (PropertyData.addMatchUnorderedForMatchesAndRanges):
2242 (PropertyData.addRangeUnorderedForMatchesAndRanges):
2243 (PropertyData.addMatchUnordered):
2244 (PropertyData.addRangeUnordered):
2245 (PropertyData.removeMatchFromRanges):
2246 (PropertyData.removeMatch):
2247 (PropertyData.dumpMatchData):
2248 (PropertyData.dump):
2249 (PropertyData.dumpAll):
2250 (PropertyData.dumpAll.std):
2251 (PropertyData.createAndDumpHashTable):
2254 (Scripts.parseScriptsFile):
2255 (Scripts.parseScriptExtensionsFile):
2258 (GeneralCategory.__init__):
2259 (GeneralCategory.createSpecialPropertyData):
2260 (GeneralCategory.findPropertyGroupFor):
2261 (GeneralCategory.addNextCodePoints):
2262 (GeneralCategory.parse):
2263 (GeneralCategory.dump):
2265 (BinaryProperty.__init__):
2266 (BinaryProperty.parsePropertyFile):
2267 (BinaryProperty.dump):
2268 * Scripts/hasher.py: Added.
2271 * ucd/DerivedBinaryProperties.txt: Added.
2272 * ucd/DerivedCoreProperties.txt: Added.
2273 * ucd/DerivedNormalizationProps.txt: Added.
2274 * ucd/PropList.txt: Added.
2275 * ucd/PropertyAliases.txt: Added.
2276 * ucd/PropertyValueAliases.txt: Added.
2277 * ucd/ScriptExtensions.txt: Added.
2278 * ucd/Scripts.txt: Added.
2279 * ucd/UnicodeData.txt: Added.
2280 * ucd/emoji-data.txt: Added.
2282 * yarr/YarrInterpreter.cpp:
2283 (JSC::Yarr::Interpreter::testCharacterClass):
2284 * yarr/YarrParser.h:
2285 (JSC::Yarr::Parser::parseEscape):
2286 (JSC::Yarr::Parser::parseTokens):
2287 (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
2288 (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
2289 * yarr/YarrPattern.cpp:
2290 (JSC::Yarr::CharacterClassConstructor::appendInverted):
2291 (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
2292 (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
2293 (JSC::Yarr::YarrPattern::errorMessage):
2294 (JSC::Yarr::PatternTerm::dump):
2295 * yarr/YarrPattern.h:
2296 (JSC::Yarr::CharacterRange::CharacterRange):
2297 (JSC::Yarr::CharacterClass::CharacterClass):
2298 (JSC::Yarr::YarrPattern::reset):
2299 (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
2300 * yarr/YarrUnicodeProperties.cpp: Added.
2301 (JSC::Yarr::HashTable::entry const):
2302 (JSC::Yarr::unicodeMatchPropertyValue):
2303 (JSC::Yarr::unicodeMatchProperty):
2304 (JSC::Yarr::createUnicodeCharacterClassFor):
2305 * yarr/YarrUnicodeProperties.h: Added.
2307 2017-10-09 Commit Queue <commit-queue@webkit.org>
2309 Unreviewed, rolling out r223015 and r223025.
2310 https://bugs.webkit.org/show_bug.cgi?id=178093
2312 Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
2315 Reverted changesets:
2317 "Enable gigacage on iOS"
2318 https://bugs.webkit.org/show_bug.cgi?id=177586
2319 http://trac.webkit.org/changeset/223015
2321 "Unreviewed, disable Gigacage on ARM64 Linux"
2322 https://bugs.webkit.org/show_bug.cgi?id=177586
2323 http://trac.webkit.org/changeset/223025
2325 2017-10-09 Keith Miller <keith_miller@apple.com>
2327 Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
2329 * JavaScriptCore.xcodeproj/project.pbxproj:
2331 2017-10-09 Ryan Haddad <ryanhaddad@apple.com>
2333 Unreviewed, rolling out r223022.
2335 This change introduced 18 test262 failures.
2339 "`async` should be able to be used as an imported binding
2341 https://bugs.webkit.org/show_bug.cgi?id=176573
2342 http://trac.webkit.org/changeset/223022
2344 2017-10-09 Robin Morisset <rmorisset@apple.com>
2346 Make the names of the options consistent
2347 https://bugs.webkit.org/show_bug.cgi?id=177933
2349 Reviewed by Saam Barati.
2351 I added an alias so the old spelling still works.
2352 I also fixed a bunch of typos in comments all around the codebase.
2354 * b3/B3LowerToAir.cpp:
2355 * dfg/DFGByteCodeParser.cpp:
2356 (JSC::DFG::ByteCodeParser::parseBlock):
2357 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2358 * dfg/DFGOperations.h:
2359 * dfg/DFGSSAConversionPhase.h:
2360 * dfg/DFGSpeculativeJIT.h:
2361 * ftl/FTLLowerDFGToB3.cpp:
2362 (JSC::FTL::DFG::LowerDFGToB3::lower):
2363 * ftl/FTLOSREntry.cpp:
2364 (JSC::FTL::prepareOSREntry):
2365 * jit/CallFrameShuffler.cpp:
2366 (JSC::CallFrameShuffler::prepareForTailCall):
2368 * parser/Parser.cpp:
2369 (JSC::Parser<LexerType>::parseExportDeclaration):
2370 * runtime/Options.h:
2372 2017-10-09 Oleksandr Skachkov <gskachkov@gmail.com>
2374 Safari 10 /11 problem with if (!await get(something)).
2375 https://bugs.webkit.org/show_bug.cgi?id=176685
2377 Reviewed by Saam Barati.
2379 Using unary operator before `await` lead to count it as identifier.
2380 According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
2381 and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator
2383 * parser/Parser.cpp:
2384 (JSC::Parser<LexerType>::parsePrimaryExpression):
2386 2017-10-07 Filip Pizlo <fpizlo@apple.com>
2388 direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
2389 https://bugs.webkit.org/show_bug.cgi?id=178051
2391 Reviewed by Saam Barati.
2393 After I studied the profile of this test, I found two pathologies in our code relating to
2394 prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
2395 happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
2396 to trigger these pathologies.
2398 - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
2399 this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
2400 that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
2402 - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
2403 malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
2404 a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
2405 a lot of transition tables. It's good to reduce the amount of memory those require.
2407 Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
2408 I was at it. I initially thought that this would have to be part of my solution, but it turned out
2409 not to be. I think it's worth landing anyway since it makes the code a lot more clear.
2411 This fixes the timeout in that test and probably reduces memory consumption.
2413 * JavaScriptCore.xcodeproj/project.pbxproj:
2414 * dfg/DFGOperations.cpp:
2416 (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
2417 (JSC::Heap::registerWeakGCMap):
2418 (JSC::Heap::unregisterWeakGCMap):
2420 * inspector/JSInjectedScriptHostPrototype.cpp:
2421 (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2422 * inspector/JSJavaScriptCallFramePrototype.cpp:
2423 (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2424 * runtime/ArrayIteratorPrototype.cpp:
2425 (JSC::ArrayIteratorPrototype::finishCreation):
2426 * runtime/ArrayPrototype.cpp:
2427 (JSC::ArrayPrototype::finishCreation):
2428 * runtime/AsyncFromSyncIteratorPrototype.cpp:
2429 (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
2430 * runtime/AsyncFunctionPrototype.cpp:
2431 (JSC::AsyncFunctionPrototype::finishCreation):
2432 * runtime/AsyncGeneratorFunctionPrototype.cpp:
2433 (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
2434 * runtime/AsyncGeneratorPrototype.cpp:
2435 (JSC::AsyncGeneratorPrototype::finishCreation):
2436 * runtime/AsyncIteratorPrototype.cpp:
2437 (JSC::AsyncIteratorPrototype::finishCreation):
2438 * runtime/CommonSlowPaths.cpp:
2439 (JSC::SLOW_PATH_DECL):
2440 * runtime/GeneratorFunctionPrototype.cpp:
2441 (JSC::GeneratorFunctionPrototype::finishCreation):
2442 * runtime/GeneratorPrototype.cpp:
2443 (JSC::GeneratorPrototype::finishCreation):
2444 * runtime/IndexingType.h:
2445 * runtime/IteratorPrototype.cpp:
2446 (JSC::IteratorPrototype::finishCreation):
2447 * runtime/JSCInlines.h:
2449 * runtime/JSCellInlines.h:
2450 (JSC::JSCell::mayBePrototype const):
2451 (JSC::JSCell::didBecomePrototype):
2452 * runtime/JSObject.cpp:
2453 (JSC::JSObject::notifyPresenceOfIndexedAccessors):
2454 (JSC::JSObject::setPrototypeDirect):
2455 * runtime/JSProxy.cpp:
2456 (JSC::JSProxy::setTarget):
2457 * runtime/MapIteratorPrototype.cpp:
2458 (JSC::MapIteratorPrototype::finishCreation):
2459 * runtime/MapPrototype.cpp:
2460 (JSC::MapPrototype::finishCreation):
2461 * runtime/ObjectPrototype.cpp:
2462 (JSC::ObjectPrototype::finishCreation):
2463 * runtime/PrototypeKey.h: Added.
2464 (JSC::PrototypeKey::PrototypeKey):
2465 (JSC::PrototypeKey::prototype const):
2466 (JSC::PrototypeKey::inlineCapacity const):
2467 (JSC::PrototypeKey::classInfo const):
2468 (JSC::PrototypeKey::globalObject const):
2469 (JSC::PrototypeKey::operator== const):
2470 (JSC::PrototypeKey::operator!= const):
2471 (JSC::PrototypeKey::operator bool const):
2472 (JSC::PrototypeKey::isHashTableDeletedValue const):
2473 (JSC::PrototypeKey::hash const):
2474 (JSC::PrototypeKeyHash::hash):
2475 (JSC::PrototypeKeyHash::equal):
2476 * runtime/PrototypeMap.cpp:
2477 (JSC::PrototypeMap::createEmptyStructure):
2478 (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
2479 * runtime/PrototypeMap.h:
2480 (JSC::PrototypeMap::PrototypeMap):
2481 * runtime/PrototypeMapInlines.h: Removed.
2482 * runtime/SetIteratorPrototype.cpp:
2483 (JSC::SetIteratorPrototype::finishCreation):
2484 * runtime/SetPrototype.cpp:
2485 (JSC::SetPrototype::finishCreation):
2486 * runtime/StringIteratorPrototype.cpp:
2487 (JSC::StringIteratorPrototype::finishCreation):
2488 * runtime/WeakGCMap.h:
2489 (JSC::WeakGCMapBase::~WeakGCMapBase):
2490 * runtime/WeakGCMapInlines.h:
2491 (JSC::KeyTraitsArg>::WeakGCMap):
2492 * runtime/WeakMapPrototype.cpp:
2493 (JSC::WeakMapPrototype::finishCreation):
2494 * runtime/WeakSetPrototype.cpp:
2495 (JSC::WeakSetPrototype::finishCreation):
2497 2017-10-07 Filip Pizlo <fpizlo@apple.com>
2499 Octane/splay can leak memory due to stray pointers on the stack when run from the command line
2500 https://bugs.webkit.org/show_bug.cgi?id=178054
2502 Reviewed by Saam Barati.
2504 This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
2505 most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
2506 height stays relatively constant.
2508 * dfg/DFGOperations.cpp:
2509 * dfg/DFGTierUpCheckInjectionPhase.cpp:
2510 (JSC::DFG::TierUpCheckInjectionPhase::run):
2511 * ftl/FTLOSREntry.cpp:
2513 (JSC::Heap::runCurrentPhase):
2514 * heap/MarkedAllocatorInlines.h:
2515 (JSC::MarkedAllocator::tryAllocate):
2516 (JSC::MarkedAllocator::allocate):
2517 * heap/Subspace.cpp:
2518 (JSC::Subspace::tryAllocateSlow):
2519 * jit/AssemblyHelpers.h:
2520 (JSC::AssemblyHelpers::sanitizeStackInline):
2521 * jit/ThunkGenerators.cpp:
2524 (JSC::VM::addressOfLastStackTop):
2526 2017-10-07 Yusuke Suzuki <utatane.tea@gmail.com>
2528 `async` should be able to be used as an imported binding name
2529 https://bugs.webkit.org/show_bug.cgi?id=176573
2531 Reviewed by Darin Adler.
2533 Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2534 and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2535 since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2536 For example, import declaration failed to bind imported binding to the name "async" because
2537 the parser considered ASYNC as keyword.
2539 This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2540 the current performance without using this ASYNC keyword.
2542 * parser/Keywords.table:
2543 * parser/Parser.cpp:
2544 (JSC::Parser<LexerType>::parseStatementListItem):
2545 (JSC::Parser<LexerType>::parseStatement):
2546 (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2547 (JSC::Parser<LexerType>::parseClass):
2548 (JSC::Parser<LexerType>::parseExportDeclaration):
2549 (JSC::Parser<LexerType>::parseAssignmentExpression):
2550 (JSC::Parser<LexerType>::parseProperty):
2551 (JSC::Parser<LexerType>::parsePrimaryExpression):
2552 (JSC::Parser<LexerType>::parseMemberExpression):
2553 (JSC::Parser<LexerType>::printUnexpectedTokenText):
2554 * parser/ParserTokens.h:
2555 * runtime/CommonIdentifiers.h:
2557 2017-09-29 Filip Pizlo <fpizlo@apple.com>
2559 Enable gigacage on iOS
2560 https://bugs.webkit.org/show_bug.cgi?id=177586
2562 Reviewed by JF Bastien.
2564 The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2565 executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2566 have Gigacage. So, this teaches ARM64 how to load from global variables.
2568 Also, this makes the code handle disabling the gigacage a bit better.
2570 * ftl/FTLLowerDFGToB3.cpp:
2571 (JSC::FTL::DFG::LowerDFGToB3::caged):
2572 * jit/AssemblyHelpers.h:
2573 (JSC::AssemblyHelpers::cage):
2574 (JSC::AssemblyHelpers::cageConditionally):
2575 * offlineasm/arm64.rb:
2576 * offlineasm/asm.rb:
2577 * offlineasm/instructions.rb:
2579 2017-10-06 Michael Saboff <msaboff@apple.com>
2581 Enable RegExp JIT for match only Unicode RegExp's
2582 https://bugs.webkit.org/show_bug.cgi?id=178033
2584 Reviewed by JF Bastien.
2586 I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052. Do it now.
2588 * runtime/RegExp.cpp:
2589 (JSC::RegExp::compileMatchOnly):
2591 2017-10-06 Alex Christensen <achristensen@webkit.org>
2593 Build fix after r223002.
2595 * dfg/DFGOSRExit.cpp:
2596 (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2597 (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2599 2017-10-06 Commit Queue <commit-queue@webkit.org>
2601 Unreviewed, rolling out r222791 and r222873.
2602 https://bugs.webkit.org/show_bug.cgi?id=178031
2604 Caused crashes with workers/wasm LayoutTests (Requested by
2605 ryanhaddad on #webkit).
2607 Reverted changesets:
2609 "WebAssembly: no VM / JS version of everything but Instance"
2610 https://bugs.webkit.org/show_bug.cgi?id=177473
2611 http://trac.webkit.org/changeset/222791
2613 "WebAssembly: address no VM / JS follow-ups"
2614 https://bugs.webkit.org/show_bug.cgi?id=177887
2615 http://trac.webkit.org/changeset/222873
2617 2017-10-06 Robin Morisset <rmorisset@apple.com>
2619 Avoid integer overflow in DFGStrengthReduction.cpp
2620 https://bugs.webkit.org/show_bug.cgi?id=177944
2622 Reviewed by Saam Barati.
2624 The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow.
2625 I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead.
2627 * dfg/DFGStrengthReductionPhase.cpp:
2628 (JSC::DFG::StrengthReductionPhase::handleNode):
2630 2017-10-05 Keith Miller <keith_miller@apple.com>
2632 JSC generate unified sources doesn't need to run during installhdrs.
2633 https://bugs.webkit.org/show_bug.cgi?id=177640
2635 Reviewed by Dan Bernstein.
2637 generate unified sources doesn't need to have a xcconfig file
2638 since we don't have any feature defines. Also, remove the plist
2639 because there's no plist for this...
2641 * JavaScriptCore.xcodeproj/project.pbxproj:
2643 2017-10-05 Jer Noble <jer.noble@apple.com>
2645 [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting
2646 https://bugs.webkit.org/show_bug.cgi?id=177261
2648 Reviewed by Eric Carlson.
2650 * Configurations/FeatureDefines.xcconfig:
2652 2017-10-05 Ryan Haddad <ryanhaddad@apple.com>
2654 Unreviewed, rolling out r222929.
2656 Caused assertion failures during LayoutTests.
2660 "Only add prototypes to the PrototypeMap if they're not
2662 https://bugs.webkit.org/show_bug.cgi?id=177952
2663 http://trac.webkit.org/changeset/222929
2665 2017-10-05 Carlos Alberto Lopez Perez <clopez@igalia.com>
2667 Generate a compile error if release is built without compiler optimizations
2668 https://bugs.webkit.org/show_bug.cgi?id=177665
2670 Reviewed by Brian Burg.
2672 Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2673 this files are compiled with -O0 for build speed reasons after r195639.
2675 * JavaScriptCore.xcodeproj/project.pbxproj:
2677 2017-10-05 Saam Barati <sbarati@apple.com>
2679 Only add prototypes to the PrototypeMap if they're not already present
2680 https://bugs.webkit.org/show_bug.cgi?id=177952
2682 Reviewed by Michael Saboff and JF Bastien.
2684 With poly proto, we need to call PrototypeMap::add more frequently since we don't
2685 know if the prototype is already in the map or not based solely on Structure.
2686 PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
2687 allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
2688 expensive than just checking if the prototype is in the map prior to adding it. This
2689 patch makes the change to only add the prototype if it's not already in the map. To
2690 do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
2691 This allows us to both only do a single hash table lookup and also to allocate only
2692 a single Weak handle when necessary.
2694 * runtime/PrototypeMapInlines.h:
2695 (JSC::PrototypeMap::addPrototype):
2696 * runtime/WeakGCMap.h:
2697 (JSC::WeakGCMap::add):
2699 2017-10-05 Saam Barati <sbarati@apple.com>
2701 Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
2703 * runtime/Options.cpp:
2704 (JSC::recomputeDependentOptions):
2706 2017-10-05 Saam Barati <sbarati@apple.com>
2708 Make sure all prototypes under poly proto get added into the VM's prototype map
2709 https://bugs.webkit.org/show_bug.cgi?id=177909
2711 Reviewed by Keith Miller.
2713 This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.
2715 * JavaScriptCore.xcodeproj/project.pbxproj:
2716 * bytecode/BytecodeList.json:
2717 * dfg/DFGByteCodeParser.cpp:
2718 (JSC::DFG::ByteCodeParser::parseBlock):
2719 * dfg/DFGOperations.cpp:
2720 * runtime/CommonSlowPaths.cpp:
2721 (JSC::SLOW_PATH_DECL):
2722 * runtime/JSCInlines.h:
2723 * runtime/PrototypeMap.cpp:
2724 (JSC::PrototypeMap::addPrototype): Deleted.
2725 * runtime/PrototypeMap.h:
2726 * runtime/PrototypeMapInlines.h:
2727 (JSC::PrototypeMap::isPrototype const):
2728 (JSC::PrototypeMap::addPrototype):
2730 2017-09-30 Yusuke Suzuki <utatane.tea@gmail.com>
2732 [JSC] Introduce import.meta
2733 https://bugs.webkit.org/show_bug.cgi?id=177703
2735 Reviewed by Filip Pizlo.
2737 This patch adds stage 3 `import.meta`[1].
2738 We add a new hook function moduleLoaderCreateImportMetaProperties, which creates
2739 import meta properties object to this module. And we set this object as @meta
2740 private variable in module environments. So module code can access this by accessing
2741 @meta private variable.
2743 [1]: https://github.com/tc39/proposal-import-meta
2745 * builtins/BuiltinNames.h:
2746 * builtins/ModuleLoaderPrototype.js:
2747 * bytecompiler/BytecodeGenerator.cpp:
2748 (JSC::BytecodeGenerator::BytecodeGenerator):
2750 (GlobalObject::moduleLoaderCreateImportMetaProperties):
2751 * parser/Parser.cpp:
2752 (JSC::Parser<LexerType>::parseModuleSourceElements):
2753 (JSC::Parser<LexerType>::parseMemberExpression):
2754 * runtime/JSGlobalObject.cpp:
2755 * runtime/JSGlobalObject.h:
2756 * runtime/JSModuleLoader.cpp:
2757 (JSC::JSModuleLoader::createImportMetaProperties):
2758 * runtime/JSModuleLoader.h:
2759 * runtime/JSModuleRecord.cpp:
2760 (JSC::JSModuleRecord::link):
2761 (JSC::JSModuleRecord::instantiateDeclarations):
2762 * runtime/JSModuleRecord.h:
2763 * runtime/ModuleLoaderPrototype.cpp:
2764 (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
2766 2017-10-04 Saam Barati <sbarati@apple.com>
2768 Make pertinent AccessCases watch the poly proto watchpoint
2769 https://bugs.webkit.org/show_bug.cgi?id=177765
2771 Reviewed by Keith Miller.
2773 This patch makes it so that stubs that encounter a structure with a
2774 valid poly proto watchpoint will watch the poly proto watchpoint. This
2775 ensures that if the watchpoint is fired, the stub will be cleared
2776 and have a chance to regenerate. In an ideal world, this will lead
2777 to the stub generating better code since it may never encounter the
2778 non-poly proto structure again.
2780 This patch also fixes a bug in the original poly proto code where
2781 I accidentally had a condition inverted. The bad code caused a
2782 stub that continually cached two structures which are structurally
2783 equivalent but with different prototype objects to always clear itself.
2784 The code should have been written differently. It should have only
2785 cleared if the poly proto watchpoint *was not* fired. The code
2786 accidentally cleared only if stub *was* fired.
2788 * bytecode/AccessCase.cpp:
2789 (JSC::AccessCase::commit):
2790 * bytecode/PolymorphicAccess.cpp:
2791 (JSC::PolymorphicAccess::addCases):
2792 (WTF::printInternal):
2793 * bytecode/PolymorphicAccess.h:
2794 (JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const):
2795 (JSC::AccessGenerationResult::addWatchpointToFire):
2796 (JSC::AccessGenerationResult::fireWatchpoints):
2797 (JSC::AccessGenerationResult::shouldResetStub const): Deleted.
2798 * bytecode/StructureStubInfo.cpp:
2799 (JSC::StructureStubInfo::addAccessCase):
2800 (JSC::StructureStubInfo::reset):
2801 * bytecode/Watchpoint.h:
2802 (JSC::InlineWatchpointSet::inflate):
2804 (JSC::fireWatchpointsAndClearStubIfNeeded):
2805 (JSC::tryCacheGetByID):
2806 (JSC::repatchGetByID):
2807 (JSC::tryCachePutByID):
2808 (JSC::repatchPutByID):
2811 (JSC::tryRepatchIn): Deleted.
2813 2017-10-04 Matt Baker <mattbaker@apple.com>
2815 Web Inspector: Improve CanvasManager recording events
2816 https://bugs.webkit.org/show_bug.cgi?id=177762
2818 Reviewed by Devin Rousso.
2820 * inspector/protocol/Canvas.json:
2821 Renamed events for clarity and consistency; made recording data optional.
2823 2017-10-04 JF Bastien <jfbastien@apple.com>
2825 WTF: Update std::expected to match current proposal
2826 https://bugs.webkit.org/show_bug.cgi?id=177881
2828 Reviewed by Mark Lam.
2832 * wasm/WasmB3IRGenerator.cpp:
2833 * wasm/WasmModule.cpp:
2834 (JSC::Wasm::makeValidationResult):
2835 * wasm/WasmParser.h:
2836 * wasm/WasmValidate.cpp:
2837 * wasm/generateWasmValidateInlinesHeader.py:
2841 2017-10-04 JF Bastien <jfbastien@apple.com>
2843 WebAssembly: address no VM / JS follow-ups
2844 https://bugs.webkit.org/show_bug.cgi?id=177887
2846 Reviewed by Saam Barati.
2848 All minor fixes, no functional changes.
2850 * wasm/WasmB3IRGenerator.cpp:
2851 (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2852 (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2853 (JSC::Wasm::B3IRGenerator::addCurrentMemory):
2854 (JSC::Wasm::B3IRGenerator::addCall):
2855 (JSC::Wasm::B3IRGenerator::addCallIndirect):
2856 * wasm/WasmContext.cpp:
2857 (JSC::Wasm::Context::store):
2858 * wasm/WasmMemoryMode.h:
2860 * wasm/js/JSWebAssemblyInstance.cpp:
2861 (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2862 * wasm/js/JSWebAssemblyTable.cpp:
2863 (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2864 (JSC::JSWebAssemblyTable::grow):
2866 2017-10-04 Mark Lam <mark.lam@apple.com>
2868 Add support for using Probe DFG OSR Exit behind a runtime flag.
2869 https://bugs.webkit.org/show_bug.cgi?id=177844
2870 <rdar://problem/34801425>
2872 Reviewed by Saam Barati.
2874 This is based on the code originally posted in https://bugs.webkit.org/show_bug.cgi?id=175144
2875 (in r221774 and r221832) with some optimizations and bug fixes added. The probe
2876 based DFG OSR Exit is only enabled if Options::useProbeOSRExit() is true. We're
2877 landing this behind an option switch to make it easier to tune performance using
2878 the probe based OSR exit.
2880 * JavaScriptCore.xcodeproj/project.pbxproj:
2881 * assembler/MacroAssembler.cpp:
2882 (JSC::stdFunctionCallback):
2883 * assembler/MacroAssemblerPrinter.cpp:
2884 (JSC::Printer::printCallback):
2885 * assembler/ProbeContext.cpp:
2886 (JSC::Probe::executeProbe):
2887 (JSC::Probe::flushDirtyStackPages):
2888 * assembler/ProbeContext.h:
2889 (JSC::Probe::Context::Context):
2890 (JSC::Probe::Context::arg):
2891 * assembler/ProbeFrame.h: Added.
2892 (JSC::Probe::Frame::Frame):
2893 (JSC::Probe::Frame::argument):
2894 (JSC::Probe::Frame::operand):
2895 (JSC::Probe::Frame::setArgument):
2896 (JSC::Probe::Frame::setOperand):
2897 (JSC::Probe::Frame::get):
2898 (JSC::Probe::Frame::set):
2899 * assembler/ProbeStack.cpp:
2900 (JSC::Probe::Page::lowWatermarkFromVisitingDirtyChunks):
2901 (JSC::Probe::Stack::Stack):
2902 (JSC::Probe::Stack::lowWatermarkFromVisitingDirtyPages):
2903 * assembler/ProbeStack.h:
2904 (JSC::Probe::Stack::Stack):
2905 (JSC::Probe::Stack::lowWatermark):
2906 (JSC::Probe::Stack::set):
2907 (JSC::Probe::Stack::savedStackPointer const):
2908 (JSC::Probe::Stack::setSavedStackPointer):
2909 (JSC::Probe::Stack::newStackPointer const): Deleted.
2910 (JSC::Probe::Stack::setNewStackPointer): Deleted.
2911 * bytecode/ArrayProfile.h:
2912 (JSC::ArrayProfile::observeArrayMode):
2913 * bytecode/CodeBlock.cpp:
2914 (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
2915 * bytecode/CodeBlock.h:
2916 (JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
2917 * bytecode/ExecutionCounter.h:
2918 (JSC::ExecutionCounter::hasCrossedThreshold const):
2919 (JSC::ExecutionCounter::setNewThresholdForOSRExit):
2920 * bytecode/MethodOfGettingAValueProfile.cpp:
2921 (JSC::MethodOfGettingAValueProfile::reportValue):
2922 * bytecode/MethodOfGettingAValueProfile.h:
2923 * dfg/DFGDriver.cpp:
2924 (JSC::DFG::compileImpl):
2925 * dfg/DFGJITCompiler.cpp:
2926 (JSC::DFG::JITCompiler::linkOSRExits):
2927 (JSC::DFG::JITCompiler::link):
2928 * dfg/DFGOSRExit.cpp:
2929 (JSC::DFG::jsValueFor):
2930 (JSC::DFG::restoreCalleeSavesFor):
2931 (JSC::DFG::saveCalleeSavesFor):
2932 (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2933 (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2934 (JSC::DFG::saveOrCopyCalleeSavesFor):
2935 (JSC::DFG::createDirectArgumentsDuringExit):
2936 (JSC::DFG::createClonedArgumentsDuringExit):
2937 (JSC::DFG::emitRestoreArguments):
2938 (JSC::DFG::OSRExit::executeOSRExit):
2939 (JSC::DFG::reifyInlinedCallFrames):
2940 (JSC::DFG::adjustAndJumpToTarget):
2941 (JSC::DFG::printOSRExit):
2943 (JSC::DFG::OSRExitState::OSRExitState):
2944 * dfg/DFGThunks.cpp:
2945 (JSC::DFG::osrExitThunkGenerator):
2947 * dfg/DFGVariableEventStream.cpp:
2948 (JSC::DFG::tryToSetConstantRecovery):
2949 (JSC::DFG::VariableEventStream::reconstruct const):
2950 (JSC::DFG::VariableEventStream::tryToSetConstantRecovery const): Deleted.
2951 * dfg/DFGVariableEventStream.h:
2952 * profiler/ProfilerOSRExit.h:
2953 (JSC::Profiler::OSRExit::incCount):
2954 * runtime/JSCJSValue.h:
2955 * runtime/JSCJSValueInlines.h:
2956 * runtime/Options.h:
2958 2017-10-04 Ryan Haddad <ryanhaddad@apple.com>
2960 Unreviewed, rolling out r222840.
2962 This change breaks internal builds.
2966 "Generate a compile error if release is built without compiler
2968 https://bugs.webkit.org/show_bug.cgi?id=177665
2969 http://trac.webkit.org/changeset/222840
2971 2017-10-04 Carlos Alberto Lopez Perez <clopez@igalia.com>
2973 Generate a compile error if release is built without compiler optimizations
2974 https://bugs.webkit.org/show_bug.cgi?id=177665
2976 Reviewed by Michael Catanzaro.
2978 Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2979 this files are compiled with -O0 for build speed reasons after r195639.
2981 * JavaScriptCore.xcodeproj/project.pbxproj:
2983 2017-10-03 Jon Davis <jond@apple.com>
2985 Update WebAssembly to "Supported"
2986 https://bugs.webkit.org/show_bug.cgi?id=177831
2988 Reviewed by Alexey Proskuryakov.
2990 Cleaned up Async Iteration and Object rest/spread to use "In Development"
2991 instead of "In development".
2995 2017-10-03 Saam Barati <sbarati@apple.com>
2997 Implement polymorphic prototypes
2998 https://bugs.webkit.org/show_bug.cgi?id=176391
3000 Reviewed by Filip Pizlo.
3002 This patch changes JSC's object model with respect to where the prototype
3003 of an object is stored. Previously, it was always stored as
3004 a constant value inside Structure. So an object's structure used to
3005 always tell you what its prototype is. Anytime an object changed
3006 its prototype, it would do a structure transition. This enables
3007 a large class of optimizations: just by doing a structure check,
3008 we know what the prototype is.
3010 However, this design falls down when you have many objects that
3011 have the same shape, but only differ in what their prototype value
3012 is. This arises in many JS programs. A simple, and probably common, example
3013 is when the program has a constructor inside of a function:
3017 constructor() { this.field1 = 42; ...; this.fieldN = 42; }
3018 method1() { doStuffWith(this.field); }
3019 method2() { doStuffWith(this.field); }
3024 repeatedly call foo() here.
3027 Before this patch, in the above program, each time `new C` created an
3028 object, it would create an object with a different structure. The
3029 reason for this is that each time foo is called, there is a new
3030 instance of C.prototype. However, each `new C` that was created
3031 with have identical shape sans its prototype value. This would
3032 cause all ICs that used `c` to quickly give up on any form of caching
3033 because they would see too many structures and give up and permanently
3034 divert control flow to the slow path.
3036 This patch fixes this issue by expanding the notion of where the prototype
3037 of an object is stored. There are now two notions of where the prototype
3038 is stored. A Structure can now be in two modes:
3039 1. Mono proto mode. This is the same mode as we used to have. It means
3040 the structure itself has a constant prototype value.
3041 2. Poly proto mode. This means the structure knows nothing about the
3042 prototype value itself. Objects with this structure store their prototype
3043 in normal object field storage. The structure will tell you the offset of
3044 this prototype inside the object's storage. As of today, we only reserve
3045 inline slots for the prototype field because poly proto only occurs
3046 for JSFinalObject. However, this will be expanded to support out of line
3047 offsets in a future patch when we extend poly proto to work when we inherit
3048 from builtin types like Map and Array.
3050 In this initial patch, we do poly proto style inline caching whenever
3051 we see an object that is poly proto or if an object in its prototype lookup
3052 chain is poly proto. Poly proto ICs work by verifying the lookup chain
3053 at runtime. This essentially boils down to performing structure checks
3054 up the prototype chain. In a future patch, we're going to extend object
3055 property condition set to work with objects that don't have poly proto bases.
3057 Initially, accesses that have poly proto access chains will always turn
3058 into GetById/PutById in the DFG. In a future patch, I'm going to teach
3059 the DFG how to inline certain accesses that have poly proto in the access
3062 One of most interesting parts about this patch is how we decide when to go
3063 poly proto. This patch uses a profiling based approach. An IC will inform
3064 a watchpoint that it sees an opportunity when two Structure's are structurally
3065 the same, sans the base object's prototype. This means that two structures
3066 have equivalent shapes all the way up the prototype chain. To support fast
3067 structural comparison, we compute a hash for a structure based on the properties
3068 it has. We compute this hash as we add properties to the structure. This
3069 computation is nearly free since we always add UniquedStringImpl*'s which
3070 already have their hashes computed. To compare structural equivalence, we
3071 just compare hash values all the way up the prototype chain. This means we
3072 can get hash conflicts between two structures, but it's extremely rare. First,
3073 it'll be rare for two structures to have the same hash. Secondly, we only
3074 consider structures originating from the same executable.
3076 How we set up this poly proto watchpoint is crucial to its design. When we create_this
3077 an object originating from some executable, that executable will create a Box<InlineWatchpointSet>.
3078 Each structure that originates from this executable will get a copy of that
3079 Box<InlineWatchpointSet>. As that structure transitions to new structures,
3080 they too will get a copy of that Box<InilneWatchpointSet>. Therefore, when
3081 invalidating an arbitrary structure's poly proto watchpoint, we will know
3082 the next time we create_this from that executable that it had been
3083 invalidated, and that we should create an object with a poly proto
3084 structure. We also use the pointer value of this Box<InlineWatchpointSet>
3085 to determine if two structures originated from the same executable. This
3086 pruning will severely limit the chances of getting a hash conflict in practice.
3088 This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider.
3089 It may be a 1-2% ARES-6 progression.
3091 This patch is between neutral and a 9x progression on the various tests
3092 I added. Most of the microbenchmarks are progressed by at least 50%.
3094 * JavaScriptCore.xcodeproj/project.pbxproj:
3096 * builtins/BuiltinNames.cpp:
3097 * builtins/BuiltinNames.h:
3098 (JSC::BuiltinNames::BuiltinNames):
3099 (JSC::BuiltinNames::underscoreProtoPrivateName const):
3100 * bytecode/AccessCase.cpp:
3101 (JSC::AccessCase::AccessCase):
3102 (JSC::AccessCase::create):
3103 (JSC::AccessCase::commit):
3104 (JSC::AccessCase::guardedByStructureCheck const):
3105 (JSC::AccessCase::canReplace const):
3106 (JSC::AccessCase::dump const):
3107 (JSC::AccessCase::visitWeak const):
3108 (JSC::AccessCase::propagateTransitions const):
3109 (JSC::AccessCase::generateWithGuard):
3110 (JSC::AccessCase::generateImpl):
3111 * bytecode/AccessCase.h:
3112 (JSC::AccessCase::usesPolyProto const):
3113 (JSC::AccessCase::AccessCase):
3114 * bytecode/CodeBlock.cpp:
3115 (JSC::CodeBlock::finishCreation):
3116 * bytecode/GetByIdStatus.cpp:
3117 (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3118 * bytecode/GetterSetterAccessCase.cpp:
3119 (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
3120 (JSC::GetterSetterAccessCase::create):
3121 * bytecode/GetterSetterAccessCase.h:
3122 * bytecode/InternalFunctionAllocationProfile.h:
3123 (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
3124 * bytecode/IntrinsicGetterAccessCase.cpp:
3125 (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
3126 * bytecode/IntrinsicGetterAccessCase.h:
3127 * bytecode/ModuleNamespaceAccessCase.cpp:
3128 (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
3129 * bytecode/ObjectAllocationProfile.cpp: Added.
3130 (JSC::ObjectAllocationProfile::initializeProfile):
3131 (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
3132 * bytecode/ObjectAllocationProfile.h:
3133 (JSC::ObjectAllocationProfile::clear):
3134 (JSC::ObjectAllocationProfile::initialize): Deleted.
3135 (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
3136 * bytecode/ObjectPropertyConditionSet.cpp:
3137 * bytecode/PolyProtoAccessChain.cpp: Added.
3138 (JSC::PolyProtoAccessChain::create):
3139 (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const):
3140 (JSC::PolyProtoAccessChain::operator== const):
3141 (JSC::PolyProtoAccessChain::dump const):
3142 * bytecode/PolyProtoAccessChain.h: Added.
3143 (JSC::PolyProtoAccessChain::clone):
3144 (JSC::PolyProtoAccessChain:: const):
3145 (JSC::PolyProtoAccessChain::operator!= const):
3146 (JSC::PolyProtoAccessChain::forEach const):
3147 * bytecode/PolymorphicAccess.cpp:
3148 (JSC::PolymorphicAccess::addCases):
3149 (JSC::PolymorphicAccess::regenerate):
3150 (WTF::printInternal):
3151 * bytecode/PolymorphicAccess.h:
3152 (JSC::AccessGenerationResult::shouldResetStub const):
3153 (JSC::AccessGenerationState::AccessGenerationState):
3154 * bytecode/PropertyCondition.cpp:
3155 (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
3156 * bytecode/ProxyableAccessCase.cpp:
3157 (JSC::ProxyableAccessCase::ProxyableAccessCase):
3158 (JSC::ProxyableAccessCase::create):
3159 * bytecode/ProxyableAccessCase.h:
3160 * bytecode/PutByIdStatus.cpp:
3161 (JSC::PutByIdStatus::computeForStubInfo):
3162 * bytecode/StructureStubInfo.cpp:
3163 (JSC::StructureStubInfo::addAccessCase):
3164 * dfg/DFGByteCodeParser.cpp:
3165 (JSC::DFG::ByteCodeParser::load):
3166 (JSC::DFG::ByteCodeParser::parseBlock):
3168 (JSC::DFG::Graph::canDoFastSpread):
3169 * dfg/DFGOperations.cpp:
3170 * dfg/DFGSpeculativeJIT.cpp:
3171 (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
3172 (JSC::DFG::SpeculativeJIT::compileInstanceOf):
3173 * dfg/DFGSpeculativeJIT.h:
3174 * dfg/DFGSpeculativeJIT64.cpp:
3175 (JSC::DFG::SpeculativeJIT::compile):
3176 * ftl/FTLLowerDFGToB3.cpp:
3177 (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3178 * jit/JITOpcodes.cpp:
3179 (JSC::JIT::emit_op_instanceof):
3180 * jit/JITOpcodes32_64.cpp:
3181 (JSC::JIT::emit_op_instanceof):
3183 (JSC::tryCacheGetByID):
3184 (JSC::tryCachePutByID):
3185 (JSC::tryRepatchIn):
3187 (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
3188 (WTF::DOMJITGetterBaseJSObject::createStructure):
3189 (WTF::DOMJITGetterBaseJSObject::create):
3190 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
3191 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
3192 (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
3193 (WTF::DOMJITGetterBaseJSObject::customGetter):
3194 (WTF::DOMJITGetterBaseJSObject::finishCreation):
3195 (GlobalObject::finishCreation):
3196 (functionCreateDOMJITGetterBaseJSObject):
3197 * llint/LLIntSlowPaths.cpp:
3198 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3199 * runtime/ArrayPrototype.cpp:
3200 (JSC::holesMustForwardToPrototype):
3202 (JSC::arrayProtoFuncReverse):
3203 (JSC::moveElements):
3204 * runtime/ClonedArguments.cpp:
3205 (JSC::ClonedArguments::createEmpty):
3206 (JSC::ClonedArguments::createWithInlineFrame):
3207 (JSC::ClonedArguments::createWithMachineFrame):
3208 (JSC::ClonedArguments::createByCopyingFrom):
3209 * runtime/CommonSlowPaths.cpp:
3210 (JSC::SLOW_PATH_DECL):
3211 * runtime/FunctionExecutable.cpp:
3212 (JSC::FunctionExecutable::visitChildren):
3213 * runtime/FunctionExecutable.h:
3214 * runtime/FunctionRareData.cpp:
3215 (JSC::FunctionRareData::initializeObjectAllocationProfile):
3216 * runtime/FunctionRareData.h:
3217 * runtime/InternalFunction.cpp:
3218 (JSC::InternalFunction::createSubclassStructureSlow):
3219 * runtime/JSArray.cpp:
3220 (JSC::JSArray::fastSlice):
3221 (JSC::JSArray::shiftCountWithArrayStorage):
3222 (JSC::JSArray::shiftCountWithAnyIndexingType):
3223 (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
3224 * runtime/JSArrayInlines.h:
3225 (JSC::JSArray::canFastCopy):
3226 * runtime/JSCJSValue.cpp:
3227 (JSC::JSValue::dumpInContextAssumingStructure const):
3228 * runtime/JSFunction.cpp:
3229 (JSC::JSFunction::prototypeForConstruction):
3230 (JSC::JSFunction::allocateAndInitializeRareData):
3231 (JSC::JSFunction::initializeRareData):
3232 (JSC::JSFunction::getOwnPropertySlot):
3233 * runtime/JSFunction.h:
3234 * runtime/JSMap.cpp:
3235 (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
3236 (JSC::JSMap::canCloneFastAndNonObservable):
3237 * runtime/JSObject.cpp:
3238 (JSC::JSObject::putInlineSlow):
3239 (JSC::JSObject::createInitialIndexedStorage):
3240 (JSC::JSObject::createArrayStorage):
3241 (JSC::JSObject::convertUndecidedToArrayStorage):
3242 (JSC::JSObject::convertInt32ToArrayStorage):
3243 (JSC::JSObject::convertDoubleToArrayStorage):
3244 (JSC::JSObject::convertContiguousToArrayStorage):
3245 (JSC::JSObject::ensureInt32Slow):
3246 (JSC::JSObject::ensureDoubleSlow):
3247 (JSC::JSObject::ensureContiguousSlow):
3248 (JSC::JSObject::ensureArrayStorageSlow):
3249 (JSC::JSObject::setPrototypeDirect):
3250 (JSC::JSObject::ordinaryToPrimitive const):
3251 (JSC::JSObject::putByIndexBeyondVectorLength):
3252 (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
3253 (JSC::JSObject::getEnumerableLength):
3254 (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
3255 (JSC::JSObject::prototypeChainMayInterceptStoreTo):
3256 (JSC::JSObject::needsSlowPutIndexing const):
3257 (JSC::JSObject::suggestedArrayStorageTransition const):
3258 * runtime/JSObject.h:
3259 (JSC::JSObject::finishCreation):
3260 (JSC::JSObject::getPrototypeDirect const):
3261 (JSC::JSObject::getPropertySlot):
3262 * runtime/JSObjectInlines.h:
3263 (JSC::JSObject::getPropertySlot):
3264 (JSC::JSObject::getNonIndexPropertySlot):
3265 (JSC::JSObject::putInlineForJSObject):
3266 * runtime/JSPropertyNameEnumerator.h:
3267 (JSC::propertyNameEnumerator):
3268 * runtime/JSSet.cpp:
3269 (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
3270 (JSC::JSSet::canCloneFastAndNonObservable):
3271 * runtime/LazyClassStructure.h:
3272 (JSC::LazyClassStructure::prototypeConcurrently const): Deleted.
3273 * runtime/Operations.cpp:
3274 (JSC::normalizePrototypeChain):
3275 * runtime/Operations.h:
3276 * runtime/Options.h:
3277 * runtime/PrototypeMap.cpp:
3278 (JSC::PrototypeMap::createEmptyStructure):
3279 (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
3280 (JSC::PrototypeMap::emptyObjectStructureForPrototype):
3281 (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
3282 * runtime/PrototypeMap.h:
3283 * runtime/Structure.cpp:
3284 (JSC::Structure::Structure):
3285 (JSC::Structure::create):
3286 (JSC::Structure::holesMustForwardToPrototype const):
3287 (JSC::Structure::changePrototypeTransition):
3288 (JSC::Structure::isCheapDuringGC):
3289 (JSC::Structure::toStructureShape):
3290 (JSC::Structure::dump const):
3291 (JSC::Structure::canCachePropertyNameEnumerator const):
3292 (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted.
3293 (JSC::Structure::needsSlowPutIndexing const): Deleted.
3294 (JSC::Structure::suggestedArrayStorageTransition const): Deleted.
3295 (JSC::Structure::prototypeForLookup const): Deleted.
3296 (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted.
3297 (JSC::Structure::canUseForAllocationsOf): Deleted.
3298 * runtime/Structure.h:
3299 * runtime/StructureChain.h:
3300 * runtime/StructureInlines.h:
3301 (JSC::Structure::create):
3302 (JSC::Structure::storedPrototypeObject const):
3303 (JSC::Structure::storedPrototypeStructure const):
3304 (JSC::Structure::storedPrototype const):
3305 (JSC::prototypeForLookupPrimitiveImpl):
git://git.webkit.org / WebKit-https.git / blob