[JSC] Grown region of WasmTable should be initialized with null
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-06-16  Yusuke Suzuki  <ysuzuki@apple.com>
2
3         [JSC] Grown region of WasmTable should be initialized with null
4         https://bugs.webkit.org/show_bug.cgi?id=198903
5
6         Reviewed by Saam Barati.
7
8         Grown region of Wasmtable is now empty. We should initialize it with null.
9         We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
10         align to the naming convention.
11
12         * wasm/WasmTable.cpp:
13         (JSC::Wasm::Table::grow):
14         (JSC::Wasm::Table::visitAggregate):
15         (JSC::Wasm::Table::visitChildren): Deleted.
16         * wasm/WasmTable.h:
17         * wasm/js/JSWebAssemblyTable.cpp:
18         (JSC::JSWebAssemblyTable::visitChildren):
19
20 2019-06-14  Keith Miller  <keith_miller@apple.com>
21
22         Restore PAC based cage.
23         https://bugs.webkit.org/show_bug.cgi?id=198872
24
25         Rubber-stamped by Saam Barati.
26
27         * assembler/MacroAssemblerARM64.h:
28         (JSC::MacroAssemblerARM64::bitFieldInsert64):
29         * assembler/MacroAssemblerARM64E.h:
30         * assembler/testmasm.cpp:
31         (JSC::testCagePreservesPACFailureBit):
32         (JSC::run):
33         * dfg/DFGSpeculativeJIT.cpp:
34         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
35         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
36         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
37         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
38         * ftl/FTLLowerDFGToB3.cpp:
39         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
40         (JSC::FTL::DFG::LowerDFGToB3::caged):
41         * jit/AssemblyHelpers.h:
42         (JSC::AssemblyHelpers::cageWithoutUntagging):
43         (JSC::AssemblyHelpers::cageConditionally):
44         (JSC::AssemblyHelpers::cage): Deleted.
45         * jit/JITPropertyAccess.cpp:
46         (JSC::JIT::emitIntTypedArrayGetByVal):
47         (JSC::JIT::emitFloatTypedArrayGetByVal):
48         (JSC::JIT::emitIntTypedArrayPutByVal):
49         (JSC::JIT::emitFloatTypedArrayPutByVal):
50         * llint/LowLevelInterpreter.asm:
51         * llint/LowLevelInterpreter64.asm:
52         * offlineasm/arm64.rb:
53         * offlineasm/instructions.rb:
54         * offlineasm/registers.rb:
55         * wasm/WasmAirIRGenerator.cpp:
56         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
57         (JSC::Wasm::AirIRGenerator::addCallIndirect):
58         * wasm/WasmB3IRGenerator.cpp:
59         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
60         (JSC::Wasm::B3IRGenerator::addCallIndirect):
61         * wasm/WasmBinding.cpp:
62         (JSC::Wasm::wasmToWasm):
63         * wasm/js/JSToWasm.cpp:
64         (JSC::Wasm::createJSToWasmWrapper):
65         * wasm/js/WebAssemblyFunction.cpp:
66         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
67
68 2019-06-13  Yusuke Suzuki  <ysuzuki@apple.com>
69
70         Yarr bytecode compilation failure should be gracefully handled
71         https://bugs.webkit.org/show_bug.cgi?id=198700
72
73         Reviewed by Michael Saboff.
74
75         Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
76         We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
77         We also harden Yarr's consumed character calculation by using Checked.
78
79         [1]: https://bugs.webkit.org/show_bug.cgi?id=185755
80
81         * inspector/ContentSearchUtilities.cpp:
82         (Inspector::ContentSearchUtilities::findMagicComment):
83         * runtime/RegExp.cpp:
84         (JSC::RegExp::byteCodeCompileIfNecessary):
85         (JSC::RegExp::compile):
86         (JSC::RegExp::compileMatchOnly):
87         * runtime/RegExpInlines.h:
88         (JSC::RegExp::matchInline):
89         * yarr/YarrErrorCode.cpp:
90         (JSC::Yarr::errorMessage):
91         (JSC::Yarr::errorToThrow):
92         * yarr/YarrErrorCode.h:
93         * yarr/YarrInterpreter.cpp:
94         (JSC::Yarr::ByteCompiler::ByteCompiler):
95         (JSC::Yarr::ByteCompiler::compile):
96         (JSC::Yarr::ByteCompiler::atomCharacterClass):
97         (JSC::Yarr::ByteCompiler::atomBackReference):
98         (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
99         (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
100         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
101         (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
102         (JSC::Yarr::ByteCompiler::popParenthesesStack):
103         (JSC::Yarr::ByteCompiler::closeAlternative):
104         (JSC::Yarr::ByteCompiler::closeBodyAlternative):
105         (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
106         (JSC::Yarr::ByteCompiler::alternativeDisjunction):
107         (JSC::Yarr::ByteCompiler::emitDisjunction):
108
109 2019-06-12  Yusuke Suzuki  <ysuzuki@apple.com>
110
111         [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
112         https://bugs.webkit.org/show_bug.cgi?id=198770
113
114         Reviewed by Saam Barati.
115
116         Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
117         are the following.
118
119             if (callee == patchableCallee) {
120                 restore callee saves for tail call
121                 prepare for tail call
122                 jump to the target function
123             }
124             restore callee saves for slow path
125             call the slow path function
126
127         And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
128         patches the above `if` statement with the jump to the stub.
129
130             jump to the polymorphic call stub
131
132         This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
133         "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
134         correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
135         This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
136         in that path.
137
138         This patch does that skips after restoring callee saves.
139
140         * bytecode/CallLinkInfo.cpp:
141         (JSC::CallLinkInfo::CallLinkInfo):
142         * bytecode/CallLinkInfo.h:
143         (JSC::CallLinkInfo::setUpCall):
144         (JSC::CallLinkInfo::calleeGPR):
145         (JSC::CallLinkInfo::setCalleeGPR): Deleted.
146         * jit/Repatch.cpp:
147         (JSC::revertCall):
148         (JSC::linkVirtualFor):
149         (JSC::linkPolymorphicCall):
150         * jit/Repatch.h:
151         * jit/ThunkGenerators.cpp:
152         (JSC::virtualThunkFor):
153
154 2019-06-12  Commit Queue  <commit-queue@webkit.org>
155
156         Unreviewed, rolling out r246322.
157         https://bugs.webkit.org/show_bug.cgi?id=198796
158
159         "It's a huge page load regression on iOS" (Requested by
160         saamyjoon on #webkit).
161
162         Reverted changeset:
163
164         "Roll out PAC cage"
165         https://bugs.webkit.org/show_bug.cgi?id=198726
166         https://trac.webkit.org/changeset/246322
167
168 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
169
170         JSC should throw if proxy set returns falsish in strict mode context
171         https://bugs.webkit.org/show_bug.cgi?id=177398
172
173         Reviewed by Yusuke Suzuki.
174
175         Throw TypeError exception if Proxy's `set` trap returns falsy value.
176         (step 6.c of https://tc39.es/ecma262/#sec-putvalue)
177
178         * runtime/ProxyObject.cpp:
179         (JSC::ProxyObject::performPut):
180         (JSC::ProxyObject::put):
181         (JSC::ProxyObject::putByIndexCommon):
182         * runtime/ProxyObject.h:
183
184 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
185
186         Error message for non-callable Proxy `construct` trap is misleading
187         https://bugs.webkit.org/show_bug.cgi?id=198637
188
189         Reviewed by Saam Barati.
190
191         Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].
192
193         * runtime/ProxyObject.cpp:
194         (JSC::performProxyConstruct): Tweak error message.
195
196 2019-06-10  Tadeu Zagallo  <tzagallo@apple.com>
197
198         AI BitURShift's result should not be unsigned
199         https://bugs.webkit.org/show_bug.cgi?id=198689
200         <rdar://problem/51550063>
201
202         Reviewed by Saam Barati.
203
204         Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
205         This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
206         get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
207         all we have to do is store the result as a signed int32.
208
209         * dfg/DFGAbstractInterpreterInlines.h:
210
211 2019-06-11  Michael Catanzaro  <mcatanzaro@igalia.com>
212
213         Unreviewed build warning fixes
214
215         Silence -Wreturn-type warning
216
217         * wasm/WasmTable.cpp:
218         (JSC::Wasm::Table::tryCreate):
219
220 2019-06-11  Saam Barati  <sbarati@apple.com>
221
222         Roll out PAC cage
223         https://bugs.webkit.org/show_bug.cgi?id=198726
224
225         Reviewed by Keith Miller.
226
227         This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
228         
229         The resulting state we're in is we have Gigacage enabled on arm64.
230         There is no more PAC caging.
231
232         We're doing this because there are performance issues with PAC caging
233         that we haven't resolved yet.
234
235         * assembler/CPU.h:
236         (JSC::isARM64E): Deleted.
237         * assembler/MacroAssemblerARM64E.h:
238         (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
239         (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
240         (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
241         * b3/B3LowerToAir.cpp:
242         * b3/B3PatchpointSpecial.cpp:
243         (JSC::B3::PatchpointSpecial::admitsStack):
244         * b3/B3StackmapSpecial.cpp:
245         (JSC::B3::StackmapSpecial::forEachArgImpl):
246         (JSC::B3::StackmapSpecial::isArgValidForRep):
247         * b3/B3Validate.cpp:
248         * b3/B3ValueRep.cpp:
249         (JSC::B3::ValueRep::addUsedRegistersTo const):
250         (JSC::B3::ValueRep::dump const):
251         (WTF::printInternal):
252         * b3/B3ValueRep.h:
253         (JSC::B3::ValueRep::ValueRep):
254         (JSC::B3::ValueRep::isReg const):
255         * dfg/DFGOperations.cpp:
256         (JSC::DFG::newTypedArrayWithSize):
257         * dfg/DFGSpeculativeJIT.cpp:
258         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
259         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
260         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
261         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
262         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
263         * dfg/DFGSpeculativeJIT.h:
264         * dfg/DFGSpeculativeJIT64.cpp:
265         (JSC::DFG::SpeculativeJIT::compile):
266         * ftl/FTLLowerDFGToB3.cpp:
267         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
268         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
269         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
270         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
271         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
272         (JSC::FTL::DFG::LowerDFGToB3::caged):
273         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
274         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
275         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
276         * heap/ConservativeRoots.cpp:
277         (JSC::ConservativeRoots::genericAddPointer):
278         * jit/AssemblyHelpers.h:
279         (JSC::AssemblyHelpers::cageConditionally):
280         * jit/IntrinsicEmitter.cpp:
281         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
282         * jit/JITPropertyAccess.cpp:
283         (JSC::JIT::emitDirectArgumentsGetByVal):
284         (JSC::JIT::emitIntTypedArrayGetByVal):
285         (JSC::JIT::emitFloatTypedArrayGetByVal):
286         (JSC::JIT::emitIntTypedArrayPutByVal):
287         (JSC::JIT::emitFloatTypedArrayPutByVal):
288         * jit/PolymorphicCallStubRoutine.cpp:
289         (JSC::PolymorphicCallNode::clearCallLinkInfo):
290         * jit/RegisterSet.h:
291         * llint/LowLevelInterpreter64.asm:
292         * runtime/ArrayBuffer.cpp:
293         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
294         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
295         (JSC::ArrayBufferContents::ArrayBufferContents):
296         (JSC::ArrayBufferContents::destroy):
297         (JSC::ArrayBufferContents::tryAllocate):
298         (JSC::ArrayBufferContents::makeShared):
299         (JSC::ArrayBufferContents::copyTo):
300         * runtime/ArrayBuffer.h:
301         (JSC::SharedArrayBufferContents::data const):
302         (JSC::ArrayBufferContents::data const):
303         (JSC::ArrayBuffer::data):
304         (JSC::ArrayBuffer::data const):
305         (JSC::ArrayBuffer::byteLength const):
306         * runtime/ArrayBufferView.cpp:
307         (JSC::ArrayBufferView::ArrayBufferView):
308         * runtime/ArrayBufferView.h:
309         (JSC::ArrayBufferView::baseAddress const):
310         (JSC::ArrayBufferView::setRangeImpl):
311         (JSC::ArrayBufferView::getRangeImpl):
312         (JSC::ArrayBufferView::byteLength const): Deleted.
313         * runtime/CachedTypes.cpp:
314         (JSC::CachedScopedArgumentsTable::encode):
315         (JSC::CachedScopedArgumentsTable::decode const):
316         * runtime/CagedBarrierPtr.h:
317         (JSC::CagedBarrierPtr::CagedBarrierPtr):
318         (JSC::CagedBarrierPtr::set):
319         (JSC::CagedBarrierPtr::get const):
320         (JSC::CagedBarrierPtr::getMayBeNull const):
321         (JSC::CagedBarrierPtr::operator== const):
322         (JSC::CagedBarrierPtr::operator!= const):
323         (JSC::CagedBarrierPtr::operator bool const):
324         (JSC::CagedBarrierPtr::setWithoutBarrier):
325         (JSC::CagedBarrierPtr::operator* const):
326         (JSC::CagedBarrierPtr::operator-> const):
327         (JSC::CagedBarrierPtr::operator[] const):
328         (JSC::CagedBarrierPtr::getUnsafe const): Deleted.
329         (JSC::CagedBarrierPtr::at const): Deleted.
330         * runtime/DataView.cpp:
331         (JSC::DataView::DataView):
332         * runtime/DataView.h:
333         (JSC::DataView::get):
334         (JSC::DataView::set):
335         * runtime/DirectArguments.cpp:
336         (JSC::DirectArguments::visitChildren):
337         (JSC::DirectArguments::overrideThings):
338         (JSC::DirectArguments::unmapArgument):
339         * runtime/DirectArguments.h:
340         * runtime/GenericArguments.h:
341         * runtime/GenericArgumentsInlines.h:
342         (JSC::GenericArguments<Type>::visitChildren):
343         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
344         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
345         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
346         * runtime/GenericTypedArrayView.h:
347         * runtime/GenericTypedArrayViewInlines.h:
348         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
349         * runtime/JSArrayBufferView.cpp:
350         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
351         (JSC::JSArrayBufferView::JSArrayBufferView):
352         (JSC::JSArrayBufferView::finalize):
353         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
354         * runtime/JSArrayBufferView.h:
355         (JSC::JSArrayBufferView::ConstructionContext::vector const):
356         (JSC::JSArrayBufferView::isNeutered):
357         (JSC::JSArrayBufferView::vector const):
358         (JSC::JSArrayBufferView::hasVector const): Deleted.
359         * runtime/JSGenericTypedArrayViewInlines.h:
360         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
361         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
362         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
363         * runtime/Options.h:
364         * runtime/ScopedArgumentsTable.cpp:
365         (JSC::ScopedArgumentsTable::clone):
366         (JSC::ScopedArgumentsTable::setLength):
367         * runtime/ScopedArgumentsTable.h:
368         * runtime/SymbolTable.h:
369         * wasm/WasmAirIRGenerator.cpp:
370         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
371         (JSC::Wasm::AirIRGenerator::addCallIndirect):
372         * wasm/WasmB3IRGenerator.cpp:
373         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
374         (JSC::Wasm::B3IRGenerator::addCallIndirect):
375         * wasm/WasmBBQPlan.cpp:
376         (JSC::Wasm::BBQPlan::complete):
377         * wasm/WasmBinding.cpp:
378         (JSC::Wasm::wasmToWasm):
379         * wasm/WasmInstance.h:
380         (JSC::Wasm::Instance::cachedMemory const):
381         (JSC::Wasm::Instance::updateCachedMemory):
382         * wasm/WasmMemory.cpp:
383         (JSC::Wasm::Memory::Memory):
384         (JSC::Wasm::Memory::~Memory):
385         (JSC::Wasm::Memory::grow):
386         (JSC::Wasm::Memory::dump const):
387         * wasm/WasmMemory.h:
388         (JSC::Wasm::Memory::memory const):
389         * wasm/js/JSToWasm.cpp:
390         (JSC::Wasm::createJSToWasmWrapper):
391         * wasm/js/WebAssemblyFunction.cpp:
392         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
393
394 2019-06-10  Basuke Suzuki  <Basuke.Suzuki@sony.com>
395
396         [WinCairo] Remove build warning from RemoteInspector.
397         https://bugs.webkit.org/show_bug.cgi?id=198724
398
399         Reviewed by Joseph Pecoraro.
400
401         In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
402         This method is to be overwritten by sub classes so that parameter name is important
403         so they are commented out rather than just removing from the definition.
404
405         * inspector/remote/RemoteInspector.h:
406
407 2019-06-10  Sam Weinig  <weinig@apple.com>
408
409         Remove Dashboard support
410         https://bugs.webkit.org/show_bug.cgi?id=198615
411
412         Reviewed by Ryosuke Niwa.
413
414         * Configurations/FeatureDefines.xcconfig:
415
416 2019-06-10  Devin Rousso  <drousso@apple.com>
417
418         Web Automation: add notifications for when remote automation is enabled/disabled
419         https://bugs.webkit.org/show_bug.cgi?id=198703
420         <rdar://problem/50588975>
421
422         Reviewed by Timothy Hatcher.
423
424         * inspector/remote/RemoteInspectorConstants.h:
425
426 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
427
428         Unreviewed, build fix for non-DFG configurations, part 2
429         https://bugs.webkit.org/show_bug.cgi?id=198023
430
431         * bytecode/CodeBlock.cpp:
432         (JSC::CodeBlock::finalizeUnconditionally):
433
434 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
435
436         Unreviewed, build fix for non-DFG configurations
437         https://bugs.webkit.org/show_bug.cgi?id=198023
438
439         * bytecode/CodeBlock.cpp:
440         (JSC::CodeBlock::finalizeUnconditionally):
441
442 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
443
444         [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
445         https://bugs.webkit.org/show_bug.cgi?id=198023
446
447         Reviewed by Saam Barati.
448
449         While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
450         When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
451         And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
452         UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
453         be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
454         navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
455         web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
456         hit the uppermost of memory footprint. But until that, we increase our memory footprint.
457
458         However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
459         time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
460         One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
461         But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.
462
463         But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
464         reuse these CodeCache since we do not have the navigation.
465
466         This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
467         cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
468         heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.
469
470             UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
471                                                                                                              ^
472                                                                                                          CodeBlock(E1)
473
474         We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
475         we will create duplicate UnlinkedCodeBlock and instructions stream for D1.
476
477                                                                                                          UnlinkedCodeBlock(D1)
478                                                                                                              ^
479                                                                                                          CodeBlock(E1)
480
481             UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)
482
483         But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
484         not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
485         While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
486         while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
487         Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.
488
489         If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
490         cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
491         will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.
492
493         This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
494         UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
495         While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
496         UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
497         by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
498         If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
499         heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
500         the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
501         good starting point.
502
503         Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
504         It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
505         If we want to get more memory reduction for the sake of performance, we could decrease this age limit.
506
507         Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
508         memory footprint of our target application from about 6.5 MB to about 5.9 MB.
509
510         * bytecode/CodeBlock.cpp:
511         (JSC::CodeBlock::finalizeUnconditionally):
512         * bytecode/CodeBlock.h:
513         * bytecode/UnlinkedCodeBlock.cpp:
514         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
515         (JSC::UnlinkedCodeBlock::visitChildren):
516         * bytecode/UnlinkedCodeBlock.h:
517         (JSC::UnlinkedCodeBlock::age const):
518         (JSC::UnlinkedCodeBlock::resetAge):
519         * bytecode/UnlinkedFunctionExecutable.cpp:
520         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
521         (JSC::UnlinkedFunctionExecutable::visitChildren):
522         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
523         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
524         (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
525         * bytecode/UnlinkedFunctionExecutable.h:
526         * heap/Heap.cpp:
527         (JSC::Heap::finalizeUnconditionalFinalizers):
528         * runtime/CachedTypes.cpp:
529         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
530         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
531         * runtime/CodeSpecializationKind.h:
532         * runtime/Options.h:
533         * runtime/VM.cpp:
534         (JSC::VM::isInMiniMode): Deleted.
535         * runtime/VM.h:
536         (JSC::VM::isInMiniMode):
537         (JSC::VM::useUnlinkedCodeBlockJettisoning):
538
539 2019-06-10  Timothy Hatcher  <timothy@apple.com>
540
541         Integrate dark mode support for iOS.
542         https://bugs.webkit.org/show_bug.cgi?id=198687
543         rdar://problem/51545643
544
545         Reviewed by Tim Horton.
546
547         * Configurations/FeatureDefines.xcconfig:
548
549 2019-06-10  Adrian Perez de Castro  <aperez@igalia.com>
550
551         [JSC] Linker fails when unified sources are not in use
552         https://bugs.webkit.org/show_bug.cgi?id=198722
553
554         Reviewed by Keith Miller.
555
556         Added missing inclusions of headers in several files which make use of inline functions.
557
558         * b3/B3AtomicValue.cpp:
559         * b3/B3BlockInsertionSet.cpp:
560         * b3/B3FenceValue.cpp:
561         * b3/B3LowerMacrosAfterOptimizations.cpp:
562         * b3/B3PureCSE.cpp:
563         * b3/B3StackmapValue.cpp:
564         * b3/B3SwitchValue.cpp:
565         * b3/B3UseCounts.cpp:
566         * b3/B3VariableValue.cpp:
567         * b3/B3WasmAddressValue.cpp:
568         * b3/B3WasmBoundsCheckValue.cpp:
569         * ftl/FTLCompile.cpp:
570         * wasm/WasmSectionParser.cpp:
571         * wasm/WasmTable.cpp:
572         * wasm/WasmValidate.cpp:
573
574 2019-06-10  Keith Miller  <keith_miller@apple.com>
575
576         Make new Symbol/Promise API public
577         https://bugs.webkit.org/show_bug.cgi?id=198709
578
579         Reviewed by Saam Barati.
580
581         We also need to #ifdef some tests when building for older
582         platforms because the signatures for some methods are outdated on
583         those platforms.
584
585         * API/JSObjectRef.h:
586         * API/JSObjectRefPrivate.h:
587         * API/JSValue.h:
588         * API/JSValuePrivate.h:
589         * API/JSValueRef.h:
590         * API/tests/testapi.mm:
591         (testObjectiveCAPIMain):
592
593 2019-06-09  Commit Queue  <commit-queue@webkit.org>
594
595         Unreviewed, rolling out r246150, r246160, and r246166.
596         https://bugs.webkit.org/show_bug.cgi?id=198698
597
598         Regresses page loading time on iOS 13 (Requested by keith_m__
599         on #webkit).
600
601         Reverted changesets:
602
603         "Reenable Gigacage on ARM64."
604         https://bugs.webkit.org/show_bug.cgi?id=198453
605         https://trac.webkit.org/changeset/246150
606
607         "Unrevied build fix for FTL without Gigacage."
608         https://trac.webkit.org/changeset/246160
609
610         "Fix typo in cageWithoutUntagging"
611         https://bugs.webkit.org/show_bug.cgi?id=198617
612         https://trac.webkit.org/changeset/246166
613
614 2019-06-09  Yusuke Suzuki  <ysuzuki@apple.com>
615
616         [JSC] Use mergePrediction in ValuePow prediction propagation
617         https://bugs.webkit.org/show_bug.cgi?id=198648
618
619         Reviewed by Saam Barati.
620
621         We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
622         must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
623         previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.
624
625         * dfg/DFGPredictionPropagationPhase.cpp:
626
627 2019-06-07  Tadeu Zagallo  <tzagallo@apple.com>
628
629         AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
630         https://bugs.webkit.org/show_bug.cgi?id=198581
631         <rdar://problem/51099753>
632
633         Reviewed by Saam Barati.
634
635         For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
636         from the object, it gets the GetterSetter structure from the CodeBlock's global object.
637         However, that's not correct, since the global object for the base object might differ
638         from the CodeBlock's. Instead, we try to get the global object from the base, when it's
639         a constant object. Otherwise, we can't infer the value and only set the type.
640
641         * dfg/DFGAbstractInterpreterInlines.h:
642         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
643
644 2019-06-06  Devin Rousso  <drousso@apple.com>
645
646         Web Inspector: create CommandLineAPIHost lazily like the other agents
647         https://bugs.webkit.org/show_bug.cgi?id=196047
648         <rdar://problem/49087835>
649
650         Reviewed by Timothy Hatcher.
651
652         * inspector/InjectedScriptManager.h:
653         * inspector/InjectedScriptManager.cpp:
654         (Inspector::InjectedScriptManager::connect): Added.
655
656 2019-06-06  Keith Miller  <keith_miller@apple.com>
657
658         Fix typo in cageWithoutUntagging
659         https://bugs.webkit.org/show_bug.cgi?id=198617
660
661         Reviewed by Saam Barati.
662
663         * assembler/testmasm.cpp:
664         (JSC::testCagePreservesPACFailureBit):
665         * dfg/DFGSpeculativeJIT.cpp:
666         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
667         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
668         * jit/AssemblyHelpers.h:
669         (JSC::AssemblyHelpers::cageWithoutUntagging):
670         (JSC::AssemblyHelpers::cageConditionally):
671         (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.
672
673 2019-06-06  Alexey Shvayka  <shvaikalesh@gmail.com>
674
675         JSON.parse throws incorrect exception when called w/o arguments
676         https://bugs.webkit.org/show_bug.cgi?id=198574
677
678         Reviewed by Yusuke Suzuki.
679
680         Always coerce first argument to string and attempt to parse it.
681         (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)
682
683         * runtime/JSONObject.cpp:
684         (JSC::JSONProtoFuncParse): Remove argumentCount check.
685
686 2019-06-06  Keith Miller  <keith_miller@apple.com>
687
688         Unrevied build fix for FTL without Gigacage.
689
690         * ftl/FTLLowerDFGToB3.cpp:
691         (JSC::FTL::DFG::LowerDFGToB3::caged):
692
693 2019-06-06  Michael Catanzaro  <mcatanzaro@igalia.com>
694
695         aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
696         https://bugs.webkit.org/show_bug.cgi?id=198014
697
698         Reviewed by Yusuke Suzuki.
699
700         When building for aarch64, there is a huge warning spam here. It's impossible to see any
701         other warnings. This has been ongoing for so long I've begun to suspect that nobody works
702         on this architecture.
703
704         Anyway, the problem is because we need eight bits to store all possible RegisterID values,
705         but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
706         struct is still happy, so I presume the change is OK.
707
708         * assembler/ARM64Assembler.h:
709
710 2019-06-06  Keith Miller  <keith_miller@apple.com>
711
712         Reenable Gigacage on ARM64.
713         https://bugs.webkit.org/show_bug.cgi?id=198453
714
715         Reviewed by Michael Saboff.
716
717         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
718         old Gigacage however, arm64e uses both Gigacaging and PAC. In
719         order to ensure the PAC bits are not stripped in the caging
720         process we use the bit field insert instruction to take the low
721         bits from caging and the high bits from the PAC authentication.
722
723         * assembler/MacroAssemblerARM64.h:
724         (JSC::MacroAssemblerARM64::bitFieldInsert64):
725         * assembler/MacroAssemblerARM64E.h:
726         * assembler/testmasm.cpp:
727         (JSC::testCagePreservesPACFailureBit):
728         (JSC::run):
729         * dfg/DFGSpeculativeJIT.cpp:
730         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
731         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
732         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
733         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
734         * ftl/FTLLowerDFGToB3.cpp:
735         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
736         (JSC::FTL::DFG::LowerDFGToB3::caged):
737         * jit/AssemblyHelpers.h:
738         (JSC::AssemblyHelpers::cageWithoutUntaging):
739         (JSC::AssemblyHelpers::cageConditionally):
740         (JSC::AssemblyHelpers::cage): Deleted.
741         * jit/JITPropertyAccess.cpp:
742         (JSC::JIT::emitIntTypedArrayGetByVal):
743         (JSC::JIT::emitFloatTypedArrayGetByVal):
744         (JSC::JIT::emitIntTypedArrayPutByVal):
745         (JSC::JIT::emitFloatTypedArrayPutByVal):
746         * llint/LowLevelInterpreter.asm:
747         * llint/LowLevelInterpreter64.asm:
748         * offlineasm/arm64.rb:
749         * offlineasm/instructions.rb:
750         * offlineasm/registers.rb:
751         * wasm/WasmAirIRGenerator.cpp:
752         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
753         (JSC::Wasm::AirIRGenerator::addCallIndirect):
754         * wasm/WasmB3IRGenerator.cpp:
755         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
756         (JSC::Wasm::B3IRGenerator::addCallIndirect):
757         * wasm/WasmBinding.cpp:
758         (JSC::Wasm::wasmToWasm):
759         * wasm/js/JSToWasm.cpp:
760         (JSC::Wasm::createJSToWasmWrapper):
761         * wasm/js/WebAssemblyFunction.cpp:
762         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
763
764 2019-06-06  Michael Saboff  <msaboff@apple.com>
765
766         [ARM64E]: Add disassembler support for authenticated instructions
767         https://bugs.webkit.org/show_bug.cgi?id=198562
768
769         Reviewed by Keith Miller.
770
771         Added support for all the instructions supported in ARM64EAssembler.h.
772
773         * disassembler/ARM64/A64DOpcode.cpp:
774         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
775         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
776         (JSC::ARM64Disassembler::A64DOpcodeHint::format):
777         (JSC::ARM64Disassembler::A64DOpcodeHint::opName):
778         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
779         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
780         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
781         * disassembler/ARM64/A64DOpcode.h:
782         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
783         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
784         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
785         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
786         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
787         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
788         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
789         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
790         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
791         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
792         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
793         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
794         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
795         (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.
796
797 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
798
799         [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
800         https://bugs.webkit.org/show_bug.cgi?id=198398
801
802         Reviewed by Saam Barati.
803
804         Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
805         Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
806         support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
807         we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
808         restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
809         can be done statically, so this too should not restrict our threads implementation. 
810
811         * wasm/WasmAirIRGenerator.cpp:
812         (JSC::Wasm::AirIRGenerator::addTableGet):
813         (JSC::Wasm::AirIRGenerator::addTableSet):
814         (JSC::Wasm::AirIRGenerator::addCallIndirect):
815         * wasm/WasmB3IRGenerator.cpp:
816         (JSC::Wasm::B3IRGenerator::addLocal):
817         (JSC::Wasm::B3IRGenerator::addTableGet):
818         (JSC::Wasm::B3IRGenerator::addTableSet):
819         (JSC::Wasm::B3IRGenerator::addCallIndirect):
820         * wasm/WasmFormat.h:
821         (JSC::Wasm::TableInformation::TableInformation):
822         (JSC::Wasm::TableInformation::type const):
823         * wasm/WasmFunctionParser.h:
824         (JSC::Wasm::FunctionParser<Context>::parseExpression):
825         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
826         * wasm/WasmSectionParser.cpp:
827         (JSC::Wasm::SectionParser::parseTableHelper):
828         * wasm/WasmTable.cpp:
829         (JSC::Wasm::Table::Table):
830         (JSC::Wasm::Table::tryCreate):
831         (JSC::Wasm::Table::grow):
832         (JSC::Wasm::Table::clear):
833         (JSC::Wasm::Table::set):
834         (JSC::Wasm::Table::get):
835         (JSC::Wasm::Table::visitChildren):
836         (JSC::Wasm::FuncRefTable::FuncRefTable):
837         (JSC::Wasm::FuncRefTable::setFunction):
838         (JSC::Wasm::Table::~Table): Deleted.
839         (JSC::Wasm::Table::clearFunction): Deleted.
840         (JSC::Wasm::Table::setFunction): Deleted.
841         * wasm/WasmTable.h:
842         (JSC::Wasm::Table::length const):
843         (JSC::Wasm::Table::type const):
844         (JSC::Wasm::Table::setOwner):
845         (JSC::Wasm::FuncRefTable::offsetOfFunctions):
846         (JSC::Wasm::FuncRefTable::offsetOfInstances):
847         (JSC::Wasm::Table::offsetOfFunctions): Deleted.
848         (JSC::Wasm::Table::offsetOfInstances): Deleted.
849         * wasm/WasmValidate.cpp:
850         (JSC::Wasm::Validate::addTableGet):
851         (JSC::Wasm::Validate::addTableSet):
852         (JSC::Wasm::Validate::addCallIndirect):
853         * wasm/js/JSWebAssemblyTable.cpp:
854         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
855         (JSC::JSWebAssemblyTable::finishCreation):
856         (JSC::JSWebAssemblyTable::visitChildren):
857         (JSC::JSWebAssemblyTable::grow):
858         (JSC::JSWebAssemblyTable::get):
859         (JSC::JSWebAssemblyTable::set):
860         (JSC::JSWebAssemblyTable::clear):
861         (JSC::JSWebAssemblyTable::getFunction): Deleted.
862         (JSC::JSWebAssemblyTable::clearFunction): Deleted.
863         (JSC::JSWebAssemblyTable::setFunction): Deleted.
864         * wasm/js/JSWebAssemblyTable.h:
865         * wasm/js/WebAssemblyModuleRecord.cpp:
866         (JSC::WebAssemblyModuleRecord::link):
867         (JSC::WebAssemblyModuleRecord::evaluate):
868         * wasm/js/WebAssemblyTableConstructor.cpp:
869         (JSC::constructJSWebAssemblyTable):
870         * wasm/js/WebAssemblyTablePrototype.cpp:
871         (JSC::webAssemblyTableProtoFuncGet):
872         (JSC::webAssemblyTableProtoFuncSet):
873         * wasm/wasm.json:
874
875 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
876
877         WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
878         https://bugs.webkit.org/show_bug.cgi?id=198106
879
880         Reviewed by Saam Barati.
881
882         Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.
883
884         * assembler/MacroAssemblerARM64.h:
885         (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
886
887 2019-06-05  Alex Christensen  <achristensen@webkit.org>
888
889         Progress towards resurrecting Mac CMake build
890         https://bugs.webkit.org/show_bug.cgi?id=197132
891
892         Reviewed by Don Olmstead.
893
894         * API/JSScript.mm:
895         (-[JSScript readCache]):
896         (-[JSScript sourceCode]):
897         (-[JSScript jsSourceCode]):
898         (-[JSScript writeCache:]):
899         * CMakeLists.txt:
900
901 == Rolled over to ChangeLog-2019-06-05 ==