Web Inspector: Heap: lazily create the agent
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-03-19  Devin Rousso  <drousso@apple.com>
2
3         Web Inspector: Heap: lazily create the agent
4         https://bugs.webkit.org/show_bug.cgi?id=195590
5         <rdar://problem/48791750>
6
7         Reviewed by Joseph Pecoraro.
8
9         * inspector/agents/InspectorHeapAgent.h:
10         * inspector/agents/InspectorHeapAgent.cpp:
11         (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
12
13         * inspector/agents/InspectorConsoleAgent.h:
14         (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
15         * inspector/agents/InspectorConsoleAgent.cpp:
16         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
17         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
18         (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
19
20         * inspector/JSGlobalObjectInspectorController.cpp:
21         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
22         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
23
24 2019-03-19  Caio Lima  <ticaiolima@gmail.com>
25
26         [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
27         https://bugs.webkit.org/show_bug.cgi?id=194648
28
29         Reviewed by Keith Miller.
30
31         1. Making LLIntThunks singleton. 
32
33         Motivation: Former implementation has one LLIntThunk per type per VM.
34         However, the generated code for every kind of thunk is essentially the
35         same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
36         when we have 2 or more VM instantiated. Turn these thunks into
37         singleton will avoid such wasting.
38
39         Tradeoff: This change comes with a price, because we will keep thunks
40         allocated even when there is no VM instantiated. Considering WebCore use case,
41         the situation of having no VM instantiated is uncommon, since once a
42         VM is created through `commomVM()`, it will never be destroyed. Given
43         that, this change does not impact the overall memory comsumption of
44         WebCore/JSC. It also doesn't impact memory footprint, since thunks are
45         generated lazily (see results below).
46
47         Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
48         we have the assurance that JITed code will never be deallocated,
49         given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
50         To understand why we decided to make LLIntThunks singleton instead of
51         removing them, please see the comment on `llint/LLIntThunks.cpp`.
52
53         2. Making all LLIntEntrypoints singleton
54
55         Motivation: With singleton LLIntThunks, we also can have singleton
56         DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
57         avoid multiple allocations of objects with the same content.
58
59         Tradeoff: As explained before, once we allocate an entrypoint, it
60         will be alive until the program exits. However, the gains we can
61         achieve in some use cases justifies such allocations.
62
63         As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
64         `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
65         will never be less than 1.
66
67         3. Memory usage analysis
68
69         This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
70         by 2% and is neutral on JetStream 2. Following results were generated
71         running each benchmark 6 times and using 95% Student's t distribution
72         confidence interval.
73
74         microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
75             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
76             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
77
78         JetStream2 (Neutral):
79             Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
80             Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
81
82         4. Performance Analysis
83
84         This change is performance neutral on JetStream 2 and Speedometer 2.
85         See results below.:
86
87         JetStream 2 (Neutral):
88             Mean of score on ToT: 139.58 (confidence interval: 2.44)
89             Mean of score on Changes: 141.46 (confidence interval: 4.24)
90
91         Speedometer run #1
92            ToT: 110 +- 2.9
93            Changes: 110 +- 1.8
94
95         Speedometer run #2
96            ToT: 110 +- 1.6
97            Changes: 108 +- 2.3
98
99         Speedometer run #3
100            ToT: 110 +- 3.0
101            Changes: 110 +- 1.4
102
103         * jit/JSInterfaceJIT.h:
104         (JSC::JSInterfaceJIT::JSInterfaceJIT):
105         * llint/LLIntEntrypoint.cpp:
106
107         Here we are changing the usage or DirectJITCode by NativeJITCode on cases
108         where there is no difference from address of calls with and without
109         ArithCheck.
110
111         (JSC::LLInt::setFunctionEntrypoint):
112         (JSC::LLInt::setEvalEntrypoint):
113         (JSC::LLInt::setProgramEntrypoint):
114         (JSC::LLInt::setModuleProgramEntrypoint):
115         (JSC::LLInt::setEntrypoint):
116         * llint/LLIntEntrypoint.h:
117         * llint/LLIntThunks.cpp:
118         (JSC::LLInt::generateThunkWithJumpTo):
119         (JSC::LLInt::functionForCallEntryThunk):
120         (JSC::LLInt::functionForConstructEntryThunk):
121         (JSC::LLInt::functionForCallArityCheckThunk):
122         (JSC::LLInt::functionForConstructArityCheckThunk):
123         (JSC::LLInt::evalEntryThunk):
124         (JSC::LLInt::programEntryThunk):
125         (JSC::LLInt::moduleProgramEntryThunk):
126         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
127         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
128         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
129         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
130         (JSC::LLInt::evalEntryThunkGenerator): Deleted.
131         (JSC::LLInt::programEntryThunkGenerator): Deleted.
132         (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
133         * llint/LLIntThunks.h:
134         * runtime/ScriptExecutable.cpp:
135         (JSC::setupLLInt):
136         (JSC::ScriptExecutable::prepareForExecutionImpl):
137
138 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
139
140         [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
141         https://bugs.webkit.org/show_bug.cgi?id=195927
142
143         Reviewed by Mark Lam.
144
145         r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
146         This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
147
148         * runtime/RegExpConstructor.cpp:
149         (JSC::setRegExpConstructorInput):
150         (JSC::setRegExpConstructorMultiline):
151         * runtime/RegExpGlobalData.cpp:
152         (JSC::RegExpGlobalData::getBackref):
153         (JSC::RegExpGlobalData::getLastParen):
154
155 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
156
157         [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
158         https://bugs.webkit.org/show_bug.cgi?id=195901
159
160         Reviewed by Saam Barati.
161
162         It is not rare that generators do not need to have any registers to be suspended and resumed.
163         Since currently we always emit op_create_lexical_environment for generator code, we sometimes
164         create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
165         are allocated in RAMification's Basic test.
166
167         This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
168         a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
169         based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
170
171         We run RAMification in 6 times, use average of them.
172         RAMification's Basic in JIT mode shows 1.4% improvement.
173         ToT
174             Current: 55076864.00, Peak: 55080960.00
175         Patched
176             Current: 54325930.67, Peak: 54329344.00
177
178         RAMification's Basic in non-JIT mode shows 5.0% improvement.
179         ToT
180             Current: 12485290.67, Peak: 12485290.67
181         Patched
182             Current: 11894101.33, Peak: 11894101.33
183
184         * bytecode/BytecodeGeneratorification.cpp:
185         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
186         (JSC::BytecodeGeneratorification::generatorFrameData const):
187         (JSC::BytecodeGeneratorification::run):
188         * bytecode/BytecodeList.rb:
189         * bytecode/BytecodeUseDef.h:
190         (JSC::computeUsesForBytecodeOffset):
191         (JSC::computeDefsForBytecodeOffset):
192         * bytecompiler/BytecodeGenerator.cpp:
193         (JSC::BytecodeGenerator::BytecodeGenerator):
194         * dfg/DFGCapabilities.cpp:
195         (JSC::DFG::capabilityLevel):
196         * llint/LowLevelInterpreter.asm:
197
198 2019-03-18  Robin Morisset  <rmorisset@apple.com>
199
200         Remove the inline capacity of Operands
201         https://bugs.webkit.org/show_bug.cgi?id=195898
202
203         Reviewed by Yusuke Suzuki.
204
205         Operands currently has a vector with an inline capacity of 24.
206         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
207         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
208         Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
209         
210         So I removed the inline capacity of the vector in Operands, and here are the results:
211         Baseline Jetstream2:
212         159.741
213         159.746
214         159.989
215         Baseline RAMification on grouped and jit tests: (end/peak/score)
216         89.288/89.763/89.526
217         90.166/90.761/90.418
218         89.560/90.014/89.787
219         After optimization Jetstream2:
220         159.342
221         161.812
222         162.037
223         After optimization RAMification:
224         89.147/89.644/89.395
225         89.102.89.585/89.343
226         88.953/89.536/89.2444
227         
228         So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
229         I hope to land this, and get more accurate results from the bots.
230
231         * bytecode/Operands.h:
232
233 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
234
235         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
236         https://bugs.webkit.org/show_bug.cgi?id=195897
237
238         Reviewed by Keith Miller.
239
240         It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
241         I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
242         This patch adds,
243
244         1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
245         2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
246
247         While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
248         we would like to collect heap statistics and dump them to investigate Heap status more.
249
250         This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
251
252         * heap/Heap.cpp:
253         (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
254         (JSC::Heap::lastChanceToFinalize):
255         * heap/Heap.h:
256         * jsc.cpp:
257         (printUsageStatement):
258         (CommandLine::parseArguments):
259         (runJSC):
260         * runtime/Options.h:
261
262 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
263
264         [JSC] jsSubstring should resolve rope before calling JSRopeString::create
265         https://bugs.webkit.org/show_bug.cgi?id=195840
266
267         Reviewed by Geoffrey Garen.
268
269         jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
270         as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
271         So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
272         of single character substrings.
273
274         We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
275         strings to save memory.
276
277         This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
278
279         * dfg/DFGOperations.cpp:
280         * runtime/JSString.cpp:
281         (JSC::JSString::dumpToStream):
282         * runtime/JSString.h:
283         (JSC::jsSubstring):
284         (JSC::jsSubstringOfResolved):
285         (JSC::jsSingleCharacterString):
286         * runtime/RegExpCachedResult.cpp:
287         (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
288         (JSC::RegExpCachedResult::leftContext):
289         (JSC::RegExpCachedResult::rightContext):
290         (JSC::RegExpCachedResult::setInput):
291         * runtime/RegExpGlobalData.cpp:
292         (JSC::RegExpGlobalData::getBackref):
293         (JSC::RegExpGlobalData::getLastParen):
294         * runtime/StringObject.h:
295         (JSC::jsStringWithReuse):
296         (JSC::jsSubstring):
297         * runtime/StringPrototype.cpp:
298         (JSC::replaceUsingRegExpSearch):
299         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
300         (JSC::replaceUsingStringSearch):
301         (JSC::stringProtoFuncSlice):
302         (JSC::splitStringByOneCharacterImpl):
303         (JSC::stringProtoFuncSplitFast):
304         (JSC::stringProtoFuncSubstr):
305         (JSC::stringProtoFuncSubstring):
306         (JSC::stringProtoFuncToLowerCase):
307         (JSC::stringProtoFuncToUpperCase):
308         Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
309
310         * runtime/StringPrototypeInlines.h:
311         (JSC::stringSlice):
312
313 2019-03-18  Mark Lam  <mark.lam@apple.com>
314
315         Missing a ThrowScope release in JSObject::toString().
316         https://bugs.webkit.org/show_bug.cgi?id=195893
317         <rdar://problem/48970986>
318
319         Reviewed by Michael Saboff.
320
321         Placate the validator with a RELEASE_AND_RETURN().
322
323         * runtime/JSObject.cpp:
324         (JSC::JSObject::toString const):
325
326 2019-03-18  Mark Lam  <mark.lam@apple.com>
327
328         Structure::flattenDictionary() should clear unused property slots.
329         https://bugs.webkit.org/show_bug.cgi?id=195871
330         <rdar://problem/48959497>
331
332         Reviewed by Michael Saboff.
333
334         It currently attempts to do this but fails because it's actually clearing up the
335         preCapacity region instead.  The fix is simply to account for the preCapacity
336         when computing the start address of the property slots.
337
338         * runtime/Structure.cpp:
339         (JSC::Structure::flattenDictionaryStructure):
340
341 2019-03-18  Robin Morisset  <rmorisset@apple.com>
342
343         B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
344         https://bugs.webkit.org/show_bug.cgi?id=152164
345
346         Reviewed by Filip Pizlo.
347
348         Turn this: Shl(<S|Z>Shr(@x, @const), @const)
349         Into this: BitAnd(@x, -(1<<@const))
350
351         I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
352         I also modified a few adjacent tests to remove undefined behaviours.
353
354         * b3/B3ReduceStrength.cpp:
355         * b3/testb3.cpp:
356         (JSC::B3::testShlImms):
357         (JSC::B3::testShlArgImm):
358         (JSC::B3::testShlSShrArgImm):
359         (JSC::B3::testShlImms32):
360         (JSC::B3::testShlArgImm32):
361         (JSC::B3::testShlZShrArgImm32):
362         (JSC::B3::run):
363
364 2019-03-17  Robin Morisset  <rmorisset@apple.com>
365
366         ParserError can be shrunk by 8 bytes
367         https://bugs.webkit.org/show_bug.cgi?id=195496
368
369         Reviewed by Mark Lam.
370
371         * parser/ParserError.h:
372
373 2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
374
375         Fix WPE and GTK Debug builds after r243049
376         https://bugs.webkit.org/show_bug.cgi?id=195860
377
378         Unreviewed, build fix after r243049.
379
380         * runtime/StringPrototype.cpp:
381         (JSC::normalizationAffects8Bit):
382
383 2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
384
385         REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
386         https://bugs.webkit.org/show_bug.cgi?id=195858
387
388         Reviewed by Mark Lam.
389
390         r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
391         the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
392         This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
393         other places to fix the same problem. This bug is caught by existing debug tests for wasm.
394
395         * runtime/JSGlobalObject.h:
396         * wasm/js/JSWebAssemblyCompileError.cpp:
397         (JSC::createJSWebAssemblyCompileError):
398         * wasm/js/JSWebAssemblyInstance.cpp:
399         (JSC::JSWebAssemblyInstance::finalizeCreation):
400         (JSC::JSWebAssemblyInstance::create):
401         * wasm/js/JSWebAssemblyLinkError.cpp:
402         (JSC::createJSWebAssemblyLinkError):
403         * wasm/js/JSWebAssemblyModule.cpp:
404         (JSC::JSWebAssemblyModule::createStub):
405         (JSC::JSWebAssemblyModule::finishCreation):
406         * wasm/js/WasmToJS.cpp:
407         (JSC::Wasm::wasmToJSException):
408         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
409         (JSC::constructJSWebAssemblyCompileError):
410         (JSC::callJSWebAssemblyCompileError):
411         * wasm/js/WebAssemblyFunction.cpp:
412         (JSC::WebAssemblyFunction::create):
413         * wasm/js/WebAssemblyFunction.h:
414         * wasm/js/WebAssemblyInstanceConstructor.cpp:
415         (JSC::constructJSWebAssemblyInstance):
416         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
417         (JSC::constructJSWebAssemblyLinkError):
418         (JSC::callJSWebAssemblyLinkError):
419         * wasm/js/WebAssemblyMemoryConstructor.cpp:
420         (JSC::constructJSWebAssemblyMemory):
421         * wasm/js/WebAssemblyModuleConstructor.cpp:
422         (JSC::WebAssemblyModuleConstructor::createModule):
423         * wasm/js/WebAssemblyModuleRecord.cpp:
424         (JSC::WebAssemblyModuleRecord::link):
425         (JSC::WebAssemblyModuleRecord::evaluate):
426         * wasm/js/WebAssemblyPrototype.cpp:
427         (JSC::webAssemblyModuleValidateAsyncInternal):
428         (JSC::instantiate):
429         (JSC::compileAndInstantiate):
430         (JSC::webAssemblyModuleInstantinateAsyncInternal):
431         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
432         (JSC::constructJSWebAssemblyRuntimeError):
433         (JSC::callJSWebAssemblyRuntimeError):
434         * wasm/js/WebAssemblyTableConstructor.cpp:
435         (JSC::constructJSWebAssemblyTable):
436         * wasm/js/WebAssemblyToJSCallee.cpp:
437         (JSC::WebAssemblyToJSCallee::create):
438         * wasm/js/WebAssemblyToJSCallee.h:
439         * wasm/js/WebAssemblyWrapperFunction.cpp:
440         (JSC::WebAssemblyWrapperFunction::create):
441         * wasm/js/WebAssemblyWrapperFunction.h:
442
443 2019-03-16  Darin Adler  <darin@apple.com>
444
445         Improve normalization code, including moving from unorm.h to unorm2.h
446         https://bugs.webkit.org/show_bug.cgi?id=195330
447
448         Reviewed by Michael Catanzaro.
449
450         * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
451
452         * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
453         (JSC::normalizer): Added. Function to create normalizer object given
454         enumeration value indicating which is selected. Simplified because we
455         know the function will not fail and so we don't need error handling code.
456         (JSC::normalize): Changed this function to take a JSString* so we can
457         optimize the case where no normalization is needed. Added an early exit
458         if the string is stored as 8-bit and another if the string is already
459         normalized, using unorm2_isNormalized. Changed error handling to only
460         check cases that can actually fail in practice. Also did other small
461         optimizations like passing VM rather than ExecState.
462         (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
463         identical to the names used in the API and normalization parlance rather
464         than longer ones that expand the acronyms. Updated to pass JSString* to
465         the normalize function, so we can optimize 8-bit and already-normalized
466         cases, rather than callling the expensive String::upconvertedCharacters
467         function. Use throwVMRangeError.
468
469 2019-03-15  Mark Lam  <mark.lam@apple.com>
470
471         Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
472         https://bugs.webkit.org/show_bug.cgi?id=195827
473         <rdar://problem/48845513>
474
475         Reviewed by Filip Pizlo.
476
477         m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
478
479         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
480         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
481         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
482         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
483         * bytecode/ObjectPropertyCondition.cpp:
484         (JSC::ObjectPropertyCondition::dumpInContext const):
485         * bytecode/StructureStubClearingWatchpoint.cpp:
486         (JSC::StructureStubClearingWatchpoint::fireInternal):
487         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
488         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
489         * runtime/StructureRareData.cpp:
490         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
491
492 2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
493
494         [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
495         https://bugs.webkit.org/show_bug.cgi?id=195816
496
497         Reviewed by Michael Saboff.
498
499         This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
500
501         1. iteratorResultObjectStructure
502         2. WebAssembly related objects except for JSWebAssembly top-level object.
503
504         * CMakeLists.txt:
505         * DerivedSources-input.xcfilelist:
506         * DerivedSources-output.xcfilelist:
507         * DerivedSources.make:
508         * runtime/JSGlobalObject.cpp:
509         (JSC::JSGlobalObject::init):
510         (JSC::JSGlobalObject::visitChildren):
511         * runtime/JSGlobalObject.h:
512         (JSC::JSGlobalObject::iteratorResultObjectStructure const):
513         (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
514         (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
515         (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
516         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
517         * wasm/js/JSWebAssembly.cpp:
518         * wasm/js/JSWebAssembly.h:
519
520 2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
521
522         [CMake] Move test .js files into testapiScripts
523         https://bugs.webkit.org/show_bug.cgi?id=195565
524
525         Reviewed by Yusuke Suzuki.
526
527         testapi expect .js file in the testapiScripts-directory.
528
529         * shell/CMakeLists.txt:
530
531 2019-03-15  Mark Lam  <mark.lam@apple.com>
532
533         Gardening: add a missing exception check after r242991.
534         https://bugs.webkit.org/show_bug.cgi?id=195791
535
536         Unreviewed.
537
538         * tools/JSDollarVM.cpp:
539         (JSC::functionGetGetterSetter):
540
541 2019-03-15  Devin Rousso  <drousso@apple.com>
542
543         Web Inspector: provide a way to capture a screenshot of a node from within the page
544         https://bugs.webkit.org/show_bug.cgi?id=194279
545         <rdar://problem/10731573>
546
547         Reviewed by Joseph Pecoraro.
548
549         Add `console.screenshot` functionality, which displays a screenshot of a given object (if
550         able) within Web Inspector's Console tab. From there, it can be viewed and saved.
551
552         Currently, `console.screenshot` will
553          - capture an image of a `Node` (if provided)
554          - capture an image of the viewport if nothing is provided
555
556         * inspector/protocol/Console.json:
557         Add `Image` enum value to `ConsoleMessage` type.
558         * runtime/ConsoleTypes.h:
559         * inspector/ConsoleMessage.h:
560         * inspector/ConsoleMessage.cpp:
561         (Inspector::messageTypeValue):
562
563         * runtime/ConsoleClient.h:
564         * runtime/ConsoleObject.cpp:
565         (JSC::ConsoleObject::finishCreation):
566         (JSC::consoleProtoFuncScreenshot): Added.
567
568         * inspector/JSGlobalObjectConsoleClient.h:
569         * inspector/JSGlobalObjectConsoleClient.cpp:
570         (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
571
572 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
573
574         [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
575         https://bugs.webkit.org/show_bug.cgi?id=195791
576         <rdar://problem/48806130>
577
578         Reviewed by Mark Lam.
579
580         Consider the following example:
581
582             void putByVal(JSObject*, PropertyName propertyName, ...);
583
584             putByVal(object, symbol->privateName(), ...);
585
586         PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
587         It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
588         and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
589         incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
590         PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
591         before passing it to operations which takes it as PropertyName.
592
593         1. We use the code pattern like this.
594
595             auto propertyName = symbol->privateName();
596             someOperation(..., propertyName);
597
598         This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
599
600             auto propertyName = value.toPropertyKey(exec);
601             RETURN_IF_EXCEPTION(scope, { });
602             someOperation(..., propertyName);
603
604         2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
605            potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
606            and they typically need to retain PrivateName.
607
608         3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
609            BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
610            of `const Identifier&`.
611
612         Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
613         the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
614
615         * dfg/DFGOperations.cpp:
616         * jit/JITOperations.cpp:
617         (JSC::tryGetByValOptimize):
618         * runtime/JSFunction.cpp:
619         (JSC::JSFunction::setFunctionName):
620         * runtime/JSModuleLoader.cpp:
621         (JSC::printableModuleKey):
622         * runtime/JSONObject.cpp:
623         (JSC::Stringifier::Stringifier):
624         * runtime/Symbol.cpp:
625         (JSC::Symbol::descriptiveString const):
626         (JSC::Symbol::description const):
627         * runtime/Symbol.h:
628         * runtime/SymbolConstructor.cpp:
629         (JSC::symbolConstructorKeyFor):
630         * tools/JSDollarVM.cpp:
631         (JSC::functionGetGetterSetter):
632
633 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
634
635         REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
636         https://bugs.webkit.org/show_bug.cgi?id=195752
637
638         Reviewed by Saam Barati.
639
640         We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
641         was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
642         falls into wrong condition), our validation does not care AnyInt and Double representations in lower
643         tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
644         SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
645         OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
646         before entering DFG code.
647
648         This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
649
650         And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
651         in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
652         value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
653         is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
654
655         We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
656         AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
657         is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
658         and it accepts JSValues simply.
659
660         * bytecode/SpeculatedType.cpp:
661         (JSC::dumpSpeculation):
662         * dfg/DFGAbstractValue.cpp:
663         (JSC::DFG::AbstractValue::filterValueByType):
664         * dfg/DFGAbstractValue.h:
665         (JSC::DFG::AbstractValue::validateOSREntryValue const):
666         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
667         (JSC::DFG::AbstractValue::validate const): Deleted.
668         (JSC::DFG::AbstractValue::validateType const): Deleted.
669         * dfg/DFGCFAPhase.cpp:
670         (JSC::DFG::CFAPhase::run):
671         (JSC::DFG::CFAPhase::injectOSR):
672         (JSC::DFG::CFAPhase::performBlockCFA):
673         * dfg/DFGOSREntry.cpp:
674         (JSC::DFG::prepareOSREntry):
675
676 2019-03-14  Saam barati  <sbarati@apple.com>
677
678         We can't remove code after ForceOSRExit until after FixupPhase
679         https://bugs.webkit.org/show_bug.cgi?id=186916
680         <rdar://problem/41396612>
681
682         Reviewed by Yusuke Suzuki.
683
684         There was an optimization in the bytecode parser I added in r232742 that converted blocks
685         with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
686         this is incorrect because it breaks backwards propagation. For example, it
687         could incorrectly lead us to think it's safe to not check for overflow in
688         an Add because such Add has no non-int uses. Backwards propagation relies on
689         having a view over bytecode uses, and this optimization broke that. This patch
690         rolls out that optimization, as initial perf data shows it may no longer be
691         needed.
692
693         * dfg/DFGByteCodeParser.cpp:
694         (JSC::DFG::ByteCodeParser::addToGraph):
695         (JSC::DFG::ByteCodeParser::parse):
696
697 2019-03-14  Saam barati  <sbarati@apple.com>
698
699         JSScript should have an accessor saying if it's cached or not
700         https://bugs.webkit.org/show_bug.cgi?id=195783
701
702         Reviewed by Michael Saboff.
703
704         * API/JSScript.h:
705         * API/JSScript.mm:
706         (-[JSScript isUsingBytecodeCache]):
707         * API/tests/testapi.mm:
708         (testIsUsingBytecodeCacheAccessor):
709         (testObjectiveCAPI):
710
711 2019-03-14  Saam barati  <sbarati@apple.com>
712
713         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
714         https://bugs.webkit.org/show_bug.cgi?id=195782
715         <rdar://problem/48880625>
716
717         Reviewed by Michael Saboff.
718
719         This patch fixes two issues with JSScript API:
720         
721         1. There was a retain cycle causing us to never destroy a JSScript once it
722         created a JSSourceCode. The reason for this is that JSScript had a 
723         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
724         
725         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
726         
727         2. r242585 made it so that JSScript would keep the cache file descriptor open
728         (and locked) for the duration of the lifetime of the JSScript itself. Our
729         anticipation here is that it would make implementing iterative cache updates
730         easier. However, this made using the API super limiting in other ways. For
731         example, if a program had a loop that cached 3000 different JSScripts, it's
732         likely that such a program would exhaust the open file count limit. This patch
733         reverts to the behavior prior to r242585 where we just keep open the file descriptor
734         while we read or write it.
735
736         * API/JSAPIGlobalObject.mm:
737         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
738         * API/JSContext.mm:
739         (-[JSContext evaluateJSScript:]):
740         * API/JSScript.mm:
741         (-[JSScript dealloc]):
742         (-[JSScript readCache]):
743         (-[JSScript init]):
744         (-[JSScript sourceCode]):
745         (-[JSScript jsSourceCode]):
746         (-[JSScript writeCache:]):
747         (-[JSScript forceRecreateJSSourceCode]): Deleted.
748         * API/JSScriptInternal.h:
749         * API/tests/testapi.mm:
750         (testCanCacheManyFilesWithTheSameVM):
751         (testObjectiveCAPI):
752         (testCacheFileIsExclusive): Deleted.
753
754 2019-03-14  Michael Saboff  <msaboff@apple.com>
755
756         ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
757         https://bugs.webkit.org/show_bug.cgi?id=195735
758
759         Reviewed by Mark Lam.
760
761         There are two bug fixes here.
762
763         The first bug happens due to a race condition when we are compiling on a separate thread while the
764         main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
765         the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
766         compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
767         it might compile successfully the next time we try to execute it on a shallower stack.
768         The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
769         or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.
770
771         The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
772         The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
773         is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
774         Changing hasCode() to take this into account fixes the second issue.
775
776         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
777         * runtime/RegExp.h:
778         * dfg/DFGSpeculativeJIT.cpp:
779         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
780         * runtime/RegExp.h:
781
782 2019-03-14  Saam barati  <sbarati@apple.com>
783
784         Fixup uses KnownInt32 incorrectly in some nodes
785         https://bugs.webkit.org/show_bug.cgi?id=195279
786         <rdar://problem/47915654>
787
788         Reviewed by Yusuke Suzuki.
789
790         Fixup was sometimes using KnownInt32 edges when it knew some
791         incoming value is an Int32 based on what the bytecode would return.
792         However, because bytecode may result in Int32 for some node does
793         not mean we'll pick Int32 as the value format for that local. For example,
794         we may choose for a value to be represented as a double. This patch
795         corrects such uses of KnownInt32.
796
797         * dfg/DFGArgumentsEliminationPhase.cpp:
798         * dfg/DFGFixupPhase.cpp:
799         (JSC::DFG::FixupPhase::fixupNode):
800         * dfg/DFGSpeculativeJIT.cpp:
801         (JSC::DFG::SpeculativeJIT::compileArrayPush):
802         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
803         * ftl/FTLLowerDFGToB3.cpp:
804         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
805
806 2019-03-14  Keith Miller  <keith_miller@apple.com>
807
808         DFG liveness can't skip tail caller inline frames
809         https://bugs.webkit.org/show_bug.cgi?id=195715
810         <rdar://problem/46221598>
811
812         Reviewed by Saam Barati.
813
814         In order to simplify OSR exit/DFG bytecode parsing our bytecode
815         generator always emits an op_ret after any tail call. However, the
816         DFG when computing the liveness of locals, would skip any tail
817         caller inline frames. This mean that if we ended up inserting a
818         Check that would OSR to the op_ret we wouldn't have kept
819         availability data around for it.
820
821         * dfg/DFGGraph.cpp:
822         (JSC::DFG::Graph::isLiveInBytecode):
823         * dfg/DFGGraph.h:
824         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
825
826 2019-03-14  Robin Morisset  <rmorisset@apple.com>
827
828         DFG::Worklist can be shrunk by 16 bytes
829         https://bugs.webkit.org/show_bug.cgi?id=195490
830
831         Reviewed by Darin Adler.
832
833         * dfg/DFGWorklist.cpp:
834         (JSC::DFG::Worklist::Worklist):
835         * dfg/DFGWorklist.h:
836
837 2019-03-14  Devin Rousso  <drousso@apple.com>
838
839         Web Inspector: Audit: provide a way to get the contents of resources
840         https://bugs.webkit.org/show_bug.cgi?id=195266
841         <rdar://problem/48550911>
842
843         Reviewed by Joseph Pecoraro.
844
845         * inspector/InjectedScriptBase.cpp:
846         (Inspector::InjectedScriptBase::makeAsyncCall):
847         Drive-by: fix missing `else`.
848
849 2019-03-14  Devin Rousso  <drousso@apple.com>
850
851         Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
852         https://bugs.webkit.org/show_bug.cgi?id=195123
853         <rdar://problem/48450148>
854
855         Reviewed by Joseph Pecoraro.
856
857         * inspector/protocol/CSS.json:
858         Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
859         which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
860
861 2019-03-13  Caio Lima  <ticaiolima@gmail.com>
862
863         [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
864         https://bugs.webkit.org/show_bug.cgi?id=195638
865
866         Reviewed by Mark Lam.
867
868         This patch introduces a m_isShared flag to track whether the
869         JITCode is shared between many CodeBlocks. This flag is used in
870         `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
871         reporting duplicated extra memory for singleton JITCodes.
872         With those changes, we now stop counting singleton LLIntEntrypoints
873         as extra memory, since they are declared as static variables. This
874         change can potentially avoid unecessary GC pressure, because
875         extra memory is used by Heap::updateAllocationLimits() to update Heap
876         limits.
877         Even though it is hard to show performance difference for this change
878         (see results below), it is important to keep extra memory usage
879         correct. Otherwise, it can be a source of a complicated bug on
880         GC in the future.
881
882         Results from last run of Speedometer 2 comparing ToT and changes. We
883         collected those numbers running Minibrowser on a MacBook Pro 15-inch
884         with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
885         since these singleton JITCode are only used by this configuration:
886
887         Speedometer2 Run #1
888             ToT: 58.2 +- 1.1
889             changes: 57.9 +- 0.99
890
891         Speedometer2 Run #2
892             ToT: 58.5 +- 1.7
893             changes: 58.0 +- 1.5
894
895         Speedometer2 Run #2
896             ToT: 58.5 +- 0.99
897             changes: 57.1 +- 1.5
898
899         * bytecode/CodeBlock.cpp:
900         (JSC::CodeBlock::estimatedSize):
901         (JSC::CodeBlock::visitChildren):
902         * bytecode/CodeBlock.h:
903         (JSC::CodeBlock::setJITCode):
904         * jit/JITCode.cpp:
905         (JSC::JITCode::JITCode):
906         (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
907         (JSC::DirectJITCode::DirectJITCode):
908         (JSC::NativeJITCode::NativeJITCode):
909         * jit/JITCode.h:
910         (JSC::JITCode::isShared const):
911         * llint/LLIntEntrypoint.cpp:
912         (JSC::LLInt::setFunctionEntrypoint):
913         (JSC::LLInt::setEvalEntrypoint):
914         (JSC::LLInt::setProgramEntrypoint):
915         (JSC::LLInt::setModuleProgramEntrypoint):
916
917 2019-03-13  Keith Rollin  <krollin@apple.com>
918
919         Add support for new StagedFrameworks layout
920         https://bugs.webkit.org/show_bug.cgi?id=195543
921
922         Reviewed by Alexey Proskuryakov.
923
924         When creating the WebKit layout for out-of-band Safari/WebKit updates,
925         use an optional path prefix when called for.
926
927         * Configurations/Base.xcconfig:
928
929 2019-03-13  Mark Lam  <mark.lam@apple.com>
930
931         Remove unneeded --tradeDestructorBlocks option.
932         https://bugs.webkit.org/show_bug.cgi?id=195698
933         <rdar://problem/39681388>
934
935         Reviewed by Yusuke Suzuki.
936
937         There's no reason why we would ever want --tradeDestructorBlocks to be false.
938
939         Also, there was an assertion in BlockDirectory::endMarking() for when
940         (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
941         outdated because the BlockDirectory's m_empty set used to mean the set of all
942         blocks that have no live (as in not reachable by GC) objects and dead objects
943         also do not require destructors to be called on them.  The current meaning of
944         m_empty is that it is the set of all blocks that have no live objects,
945         independent of whether they needs destructors to be called on them or not.
946         The assertion is no longer valid for the new meaning of m_empty as m_empty may
947         now contain destructible blocks.  This assertion is now removed as part of this
948         patch.
949
950         * heap/BlockDirectory.cpp:
951         (JSC::BlockDirectory::endMarking):
952         * heap/LocalAllocator.cpp:
953         (JSC::LocalAllocator::tryAllocateWithoutCollecting):
954         * runtime/Options.h:
955
956 2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>
957
958         String overflow when using StringBuilder in JSC::createError
959         https://bugs.webkit.org/show_bug.cgi?id=194957
960
961         Reviewed by Mark Lam.
962
963         StringBuilder in notAFunctionSourceAppender didn't check
964         for overflows but just failed.
965
966         * runtime/ExceptionHelpers.cpp:
967         (JSC::notAFunctionSourceAppender):
968
969 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
970
971         [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
972         https://bugs.webkit.org/show_bug.cgi?id=195593
973
974         Reviewed by Keith Miller.
975
976         This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
977
978         1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
979            not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
980
981         2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
982            to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
983            each XXXPrototype / XXXConstructor can encourage the reuse of the code.
984
985         * runtime/ArrayPrototype.cpp:
986         (JSC::ArrayPrototype::create):
987         (JSC::speciesWatchpointIsValid):
988         (JSC::ArrayPrototype::destroy): Deleted.
989         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
990         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
991         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
992         * runtime/ArrayPrototype.h:
993         * runtime/JSGlobalObject.cpp:
994         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
995         we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
996         requires WatchpointSet is IsWatched state.
997         * runtime/JSGlobalObject.h:
998
999 2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>
1000
1001         [JSC] OSR entry should respect abstract values in addition to flush formats
1002         https://bugs.webkit.org/show_bug.cgi?id=195653
1003
1004         Reviewed by Mark Lam.
1005
1006         Let's consider the following graph.
1007
1008         Block #0
1009             ...
1010             27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
1011             ...
1012             28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
1013             29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
1014             30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
1015             ...
1016             73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
1017
1018         Block #1 (bc#71): (OSR target) pred, #0
1019             ...
1020            102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
1021             ...
1022
1023         CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
1024         However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
1025         Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
1026
1027         The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
1028         which is None. Then, we hit the breakpoint emitted by @102.
1029
1030         This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
1031         failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
1032
1033         * dfg/DFGOSREntry.cpp:
1034         (JSC::DFG::prepareOSREntry):
1035
1036 2019-03-12  Michael Saboff  <msaboff@apple.com>
1037
1038         REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
1039         https://bugs.webkit.org/show_bug.cgi?id=195613
1040
1041         Reviewed by Mark Lam.
1042
1043         The bug here is in Yarr JIT backreference matching code.  We are incorrectly
1044         using a checkedOffset / inputPosition correction when checking for the available
1045         length left in a string.  It is improper to do these corrections as a backreference's
1046         match length is based on what was matched in the referenced capture group and not
1047         part of the checkedOffset and inputPosition computed when we compiled the RegExp.
1048         In some cases, the resulting incorrect calculation would allow us to go past
1049         the subject string's length.  Removed these adjustments.
1050
1051         After writing tests for the first bug, found another bug where the non-greedy
1052         backreference backtracking code didn't do an "are we at the end of the input?" check.
1053         This caused an infinite loop as we'd jump from the backtracking code back to
1054         try matching one more backreference, fail and then backtrack.
1055
1056         * yarr/YarrJIT.cpp:
1057         (JSC::Yarr::YarrGenerator::generateBackReference):
1058         (JSC::Yarr::YarrGenerator::backtrackBackReference):
1059
1060 2019-03-12  Robin Morisset  <rmorisset@apple.com>
1061
1062         A lot more classes have padding that can be reduced by reordering their fields
1063         https://bugs.webkit.org/show_bug.cgi?id=195579
1064
1065         Reviewed by Mark Lam.
1066
1067         * assembler/LinkBuffer.h:
1068         * dfg/DFGArrayifySlowPathGenerator.h:
1069         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
1070         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1071         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
1072         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
1073         * dfg/DFGGraph.h:
1074         * dfg/DFGNode.h:
1075         (JSC::DFG::SwitchData::SwitchData):
1076         * dfg/DFGPlan.cpp:
1077         (JSC::DFG::Plan::Plan):
1078         * dfg/DFGPlan.h:
1079         * dfg/DFGSlowPathGenerator.h:
1080         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
1081         * dfg/DFGSpeculativeJIT.cpp:
1082         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
1083         * dfg/DFGSpeculativeJIT.h:
1084         * domjit/DOMJITSignature.h:
1085         (JSC::DOMJIT::Signature::Signature):
1086         (JSC::DOMJIT::Signature::effect):
1087         (JSC::DOMJIT::Signature::argumentCount): Deleted.
1088         * heap/MarkingConstraintSolver.h:
1089         * heap/SlotVisitor.h:
1090         * jit/CallFrameShuffleData.h:
1091         * jit/JITDivGenerator.h:
1092         * jit/SpillRegistersMode.h:
1093         * parser/Nodes.h:
1094         * profiler/ProfilerOSRExit.cpp:
1095         (JSC::Profiler::OSRExit::OSRExit):
1096         * profiler/ProfilerOSRExit.h:
1097         * runtime/ArrayBufferView.h:
1098         * runtime/SamplingProfiler.cpp:
1099         (JSC::SamplingProfiler::SamplingProfiler):
1100         * runtime/SamplingProfiler.h:
1101         * runtime/TypeSet.cpp:
1102         (JSC::StructureShape::StructureShape):
1103         * runtime/TypeSet.h:
1104         * runtime/Watchdog.h:
1105
1106 2019-03-12  Mark Lam  <mark.lam@apple.com>
1107
1108         The HasIndexedProperty node does GC.
1109         https://bugs.webkit.org/show_bug.cgi?id=195559
1110         <rdar://problem/48767923>
1111
1112         Reviewed by Yusuke Suzuki.
1113
1114         HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
1115         which can eventually call JSString::getIndex(), which can resolve a rope.
1116
1117         * dfg/DFGDoesGC.cpp:
1118         (JSC::DFG::doesGC):
1119
1120 2019-03-12  Devin Rousso  <drousso@apple.com>
1121
1122         Web Inspector: Audit: there should be a centralized place for reusable code
1123         https://bugs.webkit.org/show_bug.cgi?id=195265
1124         <rdar://problem/47040673>
1125
1126         Reviewed by Joseph Pecoraro.
1127
1128         * inspector/protocol/Audit.json:
1129         Increment version.
1130
1131 2019-03-12  Robin Morisset  <rmorisset@apple.com>
1132
1133         blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
1134         https://bugs.webkit.org/show_bug.cgi?id=195595
1135
1136         Reviewed by Saam Barati.
1137
1138         Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
1139
1140         * dfg/DFGBasicBlock.h:
1141         * dfg/DFGGraph.cpp:
1142         (JSC::DFG::Graph::blocksInPreOrder):
1143         (JSC::DFG::Graph::blocksInPostOrder):
1144
1145 2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>
1146
1147         Add Optional to Forward.h.
1148         https://bugs.webkit.org/show_bug.cgi?id=195586
1149
1150         Reviewed by Darin Adler.
1151
1152         * b3/B3Common.cpp:
1153         * b3/B3Common.h:
1154         * debugger/DebuggerParseData.cpp:
1155         * debugger/DebuggerParseData.h:
1156         * heap/HeapSnapshot.cpp:
1157         * heap/HeapSnapshot.h:
1158         * jit/PCToCodeOriginMap.cpp:
1159         * jit/PCToCodeOriginMap.h:
1160         * runtime/AbstractModuleRecord.cpp:
1161         * runtime/AbstractModuleRecord.h:
1162         * wasm/WasmInstance.h:
1163         * wasm/WasmModuleParser.h:
1164         * wasm/WasmSectionParser.cpp:
1165         * wasm/WasmSectionParser.h:
1166         * wasm/WasmStreamingParser.cpp:
1167         * wasm/WasmStreamingParser.h:
1168         * yarr/YarrFlags.cpp:
1169         * yarr/YarrFlags.h:
1170         * yarr/YarrUnicodeProperties.cpp:
1171         * yarr/YarrUnicodeProperties.h:
1172         Remove unnecessary includes from headers.
1173
1174 2019-03-11  Justin Fan  <justin_fan@apple.com>
1175
1176         [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
1177         https://bugs.webkit.org/show_bug.cgi?id=194406
1178         <rdar://problem/47892466>
1179
1180         Reviewed by Myles C. Maxfield.
1181
1182         Added WebGPU to inspector context types.
1183
1184         * inspector/protocol/Canvas.json:
1185         * inspector/scripts/codegen/generator.py:
1186
1187 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
1188
1189         [JSC] Reduce # of structures in JSGlobalObject initialization
1190         https://bugs.webkit.org/show_bug.cgi?id=195498
1191
1192         Reviewed by Darin Adler.
1193
1194         This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
1195         MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
1196
1197         * CMakeLists.txt:
1198         * DerivedSources-output.xcfilelist:
1199         * DerivedSources.make:
1200         * JavaScriptCore.xcodeproj/project.pbxproj:
1201         * runtime/ArrayIteratorPrototype.cpp:
1202         (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
1203         "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
1204         transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
1205
1206         * runtime/ArrayPrototype.cpp:
1207         (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
1208         in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
1209         any performance benefit. This change saves several structures that are not useful.
1210
1211         * runtime/ClonedArguments.cpp:
1212         (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
1213
1214         * runtime/JSGlobalObject.cpp:
1215         (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
1216         since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
1217         operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
1218         we should do here.
1219
1220         (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
1221         (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
1222
1223         * runtime/JSGlobalObject.h:
1224         * runtime/MapIteratorPrototype.cpp:
1225         (JSC::MapIteratorPrototype::finishCreation):
1226         * runtime/NullGetterFunction.h:
1227         * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
1228         we can use without-transition property addition.
1229
1230         * runtime/StringIteratorPrototype.cpp:
1231         (JSC::StringIteratorPrototype::finishCreation):
1232         * runtime/VM.cpp:
1233         (JSC::VM::VM):
1234         (JSC::VM::setIteratorStructureSlow):
1235         (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
1236         * runtime/VM.h:
1237         (JSC::VM::setIteratorStructure):
1238         (JSC::VM::mapIteratorStructure):
1239
1240 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
1241
1242         [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
1243         https://bugs.webkit.org/show_bug.cgi?id=195508
1244
1245         Reviewed by Darin Adler.
1246
1247         Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
1248         Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
1249         many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
1250
1251         This patch changes two things in BuiltinExecutables.
1252
1253         1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
1254            We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
1255
1256         2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
1257            This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
1258
1259         * builtins/BuiltinExecutables.cpp:
1260         (JSC::BuiltinExecutables::BuiltinExecutables):
1261         (JSC::BuiltinExecutables::finalizeUnconditionally):
1262         (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
1263         (JSC::BuiltinExecutables::finalize): Deleted.
1264         * builtins/BuiltinExecutables.h:
1265         (JSC::BuiltinExecutables::static_cast<unsigned>):
1266         (): Deleted.
1267         * heap/Heap.cpp:
1268         (JSC::Heap::finalizeUnconditionalFinalizers):
1269
1270 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1271
1272         IntlDateTimeFormat can be shrunk by 32 bytes
1273         https://bugs.webkit.org/show_bug.cgi?id=195504
1274
1275         Reviewed by Darin Adler.
1276
1277         * runtime/IntlDateTimeFormat.h:
1278
1279 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1280
1281         IntlCollator can be shrunk by 16 bytes
1282         https://bugs.webkit.org/show_bug.cgi?id=195503
1283
1284         Reviewed by Darin Adler.
1285
1286         * runtime/IntlCollator.h:
1287
1288 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1289
1290         IntlNumberFormat can be shrunk by 16 bytes
1291         https://bugs.webkit.org/show_bug.cgi?id=195505
1292
1293         Reviewed by Darin Adler.
1294
1295         * runtime/IntlNumberFormat.h:
1296
1297 2019-03-11  Caio Lima  <ticaiolima@gmail.com>
1298
1299         [ESNext][BigInt] Implement "~" unary operation
1300         https://bugs.webkit.org/show_bug.cgi?id=182216
1301
1302         Reviewed by Keith Miller.
1303
1304         This patch is adding support of BigInt into op_bitnot operations. In
1305         addition, we are changing ArithBitNot to handle only Number operands,
1306         while introducing a new node named ValueBitNot to handle Untyped and
1307         BigInt. This node follows the same approach we are doing into other
1308         arithimetic operations into DFG.
1309
1310         * dfg/DFGAbstractInterpreterInlines.h:
1311         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1312
1313         It is possible that fixup and prediction propagation don't convert a
1314         ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
1315         analysis are conservative. In such case, we are adding constant
1316         folding rules to ValueBitNot AI.
1317
1318         * dfg/DFGBackwardsPropagationPhase.cpp:
1319         (JSC::DFG::BackwardsPropagationPhase::propagate):
1320
1321         ValueBitNot has same rules as ArithBitNot on backwards propagation.
1322
1323         * dfg/DFGByteCodeParser.cpp:
1324         (JSC::DFG::ByteCodeParser::parseBlock):
1325
1326         We can emit ArithBitNot if we know that operand of op_bitnot is a
1327         Number or any int. Otherwise we fallback to ValueBitNot and rely on
1328         fixup to convert the node to ArithBitNot when it is possible.
1329         ValueBitNot uses heap prediction on prediction propagation and we
1330         collect its type from op_bitnot's value profiler.
1331
1332         * dfg/DFGClobberize.h:
1333         (JSC::DFG::clobberize):
1334
1335         When we have the case with ValueBitNot(BigInt), we don't clobberize
1336         world.
1337
1338         * dfg/DFGDoesGC.cpp:
1339         (JSC::DFG::doesGC):
1340
1341         ValueBitNot can GC on BigIntUse because, right now, all bitNot
1342         operation allocates temporary BigInts to perform calculations and it
1343         can potentially trigger GC.
1344
1345         * dfg/DFGFixupPhase.cpp:
1346         (JSC::DFG::FixupPhase::fixupNode):
1347
1348         ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
1349         other uses, we fallback to ArithBitNot.
1350
1351         * dfg/DFGNode.h:
1352         (JSC::DFG::Node::hasHeapPrediction):
1353         * dfg/DFGNodeType.h:
1354         * dfg/DFGOperations.cpp:
1355         (JSC::DFG::bitwiseBinaryOp):
1356
1357         This template function is abstracting the new semantics of numeric
1358         values operations on bitwise operations. These operations usually
1359         folow these steps:
1360
1361             1. rhsNumeric = GetInt32OrBigInt(rhs)
1362             2. lhsNumeric = GetInt32OrBigInt(lhs)
1363             3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
1364             4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
1365             5. return rhs <int32BitOp> lhs
1366
1367         Since we have almost the same code for every bitwise op,
1368         we use such template to avoid code duplication. The template receives
1369         Int32 and BigInt operations as parameter. Error message is received as
1370         `const char*` instead of `String&` to avoid String allocation even when
1371         there is no error to throw.
1372
1373         * dfg/DFGOperations.h:
1374         * dfg/DFGPredictionPropagationPhase.cpp:
1375         * dfg/DFGSafeToExecute.h:
1376         (JSC::DFG::safeToExecute):
1377         * dfg/DFGSpeculativeJIT.cpp:
1378         (JSC::DFG::SpeculativeJIT::compileValueBitNot):
1379
1380         ValueBitNot generates speculative code for BigIntUse and this code is a
1381         call to `operationBitNotBigInt`. This operation is faster than
1382         `operationValueBitNot` because there is no need to check types of
1383         operands and execute properly operation. We still need to check
1384         exceptions after `operationBitNotBigInt` because it can throw OOM.
1385
1386         (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
1387         * dfg/DFGSpeculativeJIT.h:
1388         * dfg/DFGSpeculativeJIT32_64.cpp:
1389         (JSC::DFG::SpeculativeJIT::compile):
1390         * dfg/DFGSpeculativeJIT64.cpp:
1391         (JSC::DFG::SpeculativeJIT::compile):
1392         * ftl/FTLCapabilities.cpp:
1393         (JSC::FTL::canCompile):
1394         * ftl/FTLLowerDFGToB3.cpp:
1395         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1396         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
1397         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
1398         * runtime/CommonSlowPaths.cpp:
1399         (JSC::SLOW_PATH_DECL):
1400         * runtime/JSBigInt.cpp:
1401         (JSC::JSBigInt::bitwiseNot):
1402         * runtime/JSBigInt.h:
1403
1404 2019-03-11  Darin Adler  <darin@apple.com>
1405
1406         Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
1407         https://bugs.webkit.org/show_bug.cgi?id=195533
1408
1409         Reviewed by Brent Fulgham.
1410
1411         * API/tests/ExecutionTimeLimitTest.cpp:
1412         (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
1413         * runtime/NumberPrototype.cpp:
1414         (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
1415         * runtime/Options.cpp:
1416         (JSC::Option::dump const): Use appendFixedPrecisionNumber.
1417
1418 2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>
1419
1420         Invalid flags in a RegExp literal should be an early SyntaxError
1421         https://bugs.webkit.org/show_bug.cgi?id=195514
1422
1423         Reviewed by Darin Adler.
1424
1425         Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
1426
1427           12.2.8.1 Static Semantics: Early Errors
1428             PrimaryExpression : RegularExpressionLiteral
1429               - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
1430                 using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
1431               - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
1432                 other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.
1433
1434         In fixing this, let's also move flag handling from runtime/ to yarr/.
1435
1436         * yarr/YarrSyntaxChecker.cpp:
1437         (JSC::Yarr::checkSyntax):
1438         Check flags before checking pattern.
1439
1440         * CMakeLists.txt:
1441         * JavaScriptCore.xcodeproj/project.pbxproj:
1442         * Sources.txt:
1443         * bytecompiler/NodesCodegen.cpp:
1444         (JSC::RegExpNode::emitBytecode):
1445         * inspector/ContentSearchUtilities.cpp:
1446         (Inspector::ContentSearchUtilities::findMagicComment):
1447         * runtime/CachedTypes.cpp:
1448         * runtime/RegExp.cpp:
1449         (JSC::RegExp::RegExp):
1450         (JSC::RegExp::createWithoutCaching):
1451         (JSC::RegExp::create):
1452         (JSC::regExpFlags): Deleted.
1453         * runtime/RegExp.h:
1454         * runtime/RegExpCache.cpp:
1455         (JSC::RegExpCache::lookupOrCreate):
1456         (JSC::RegExpCache::ensureEmptyRegExpSlow):
1457         * runtime/RegExpCache.h:
1458         * runtime/RegExpConstructor.cpp:
1459         (JSC::toFlags):
1460         (JSC::regExpCreate):
1461         (JSC::constructRegExp):
1462         * runtime/RegExpKey.h:
1463         (JSC::RegExpKey::RegExpKey):
1464         (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
1465         (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
1466         (): Deleted.
1467         * runtime/RegExpPrototype.cpp:
1468         (JSC::regExpProtoFuncCompile):
1469         * testRegExp.cpp:
1470         (parseRegExpLine):
1471         * yarr/RegularExpression.cpp:
1472         (JSC::Yarr::RegularExpression::Private::compile):
1473         * yarr/YarrFlags.cpp: Added.
1474         (JSC::Yarr::parseFlags):
1475         * yarr/YarrFlags.h: Added.
1476         * yarr/YarrInterpreter.h:
1477         (JSC::Yarr::BytecodePattern::ignoreCase const):
1478         (JSC::Yarr::BytecodePattern::multiline const):
1479         (JSC::Yarr::BytecodePattern::sticky const):
1480         (JSC::Yarr::BytecodePattern::unicode const):
1481         (JSC::Yarr::BytecodePattern::dotAll const):
1482         * yarr/YarrPattern.cpp:
1483         (JSC::Yarr::YarrPattern::compile):
1484         (JSC::Yarr::YarrPattern::YarrPattern):
1485         (JSC::Yarr::YarrPattern::dumpPattern):
1486         * yarr/YarrPattern.h:
1487         (JSC::Yarr::YarrPattern::global const):
1488         (JSC::Yarr::YarrPattern::ignoreCase const):
1489         (JSC::Yarr::YarrPattern::multiline const):
1490         (JSC::Yarr::YarrPattern::sticky const):
1491         (JSC::Yarr::YarrPattern::unicode const):
1492         (JSC::Yarr::YarrPattern::dotAll const):
1493         Move flag handling to Yarr and modernize API.
1494
1495 2019-03-09  Robin Morisset  <rmorisset@apple.com>
1496
1497         Compilation can be shrunk by 8 bytes
1498         https://bugs.webkit.org/show_bug.cgi?id=195500
1499
1500         Reviewed by Mark Lam.
1501
1502         * profiler/ProfilerCompilation.cpp:
1503         (JSC::Profiler::Compilation::Compilation):
1504         * profiler/ProfilerCompilation.h:
1505
1506 2019-03-09  Robin Morisset  <rmorisset@apple.com>
1507
1508         BinarySwitch can be shrunk by 8 bytes
1509         https://bugs.webkit.org/show_bug.cgi?id=195493
1510
1511         Reviewed by Mark Lam.
1512
1513         * jit/BinarySwitch.cpp:
1514         (JSC::BinarySwitch::BinarySwitch):
1515         * jit/BinarySwitch.h:
1516
1517 2019-03-09  Robin Morisset  <rmorisset@apple.com>
1518
1519         AsyncStackTrace can be shrunk by 8 bytes
1520         https://bugs.webkit.org/show_bug.cgi?id=195491
1521
1522         Reviewed by Mark Lam.
1523
1524         * inspector/AsyncStackTrace.h:
1525
1526 2019-03-08  Mark Lam  <mark.lam@apple.com>
1527
1528         Stack overflow crash in JSC::JSObject::hasInstance.
1529         https://bugs.webkit.org/show_bug.cgi?id=195458
1530         <rdar://problem/48710195>
1531
1532         Reviewed by Yusuke Suzuki.
1533
1534         * runtime/JSObject.cpp:
1535         (JSC::JSObject::hasInstance):
1536
1537 2019-03-08  Robin Morisset  <rmorisset@apple.com>
1538
1539         IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
1540         https://bugs.webkit.org/show_bug.cgi?id=195487
1541
1542         Reviewed by Saam Barati.
1543
1544         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1545
1546 2019-03-08  Robin Morisset  <rmorisset@apple.com>
1547
1548         TypeLocation can be shrunk by 8 bytes
1549         https://bugs.webkit.org/show_bug.cgi?id=195483
1550
1551         Reviewed by Mark Lam.
1552
1553         * bytecode/TypeLocation.h:
1554         (JSC::TypeLocation::TypeLocation):
1555
1556 2019-03-08  Robin Morisset  <rmorisset@apple.com>
1557
1558         GetByIdStatus can be shrunk by 16 bytes
1559         https://bugs.webkit.org/show_bug.cgi?id=195480
1560
1561         Reviewed by Saam Barati.
1562
1563         8 bytes from reordering fields
1564         8 more bytes by making the enum State only use 1 byte.
1565
1566         * bytecode/GetByIdStatus.cpp:
1567         (JSC::GetByIdStatus::GetByIdStatus):
1568         * bytecode/GetByIdStatus.h:
1569
1570 2019-03-08  Robin Morisset  <rmorisset@apple.com>
1571
1572         PutByIdVariant can be shrunk by 8 bytes
1573         https://bugs.webkit.org/show_bug.cgi?id=195482
1574
1575         Reviewed by Mark Lam.
1576
1577         * bytecode/PutByIdVariant.h:
1578         (JSC::PutByIdVariant::PutByIdVariant):
1579
1580 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
1581
1582         Unreviewed, follow-up after r242568
1583
1584         Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
1585
1586         * dfg/DFGAbstractInterpreterInlines.h:
1587         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1588
1589 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
1590
1591         [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
1592         https://bugs.webkit.org/show_bug.cgi?id=195447
1593
1594         Reviewed by Filip Pizlo.
1595
1596         This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
1597         caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
1598         To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
1599         to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
1600         to use `putDirectWithoutTransition` instead of `putDirect`.
1601
1602         * inspector/JSInjectedScriptHostPrototype.cpp:
1603         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1604         * inspector/JSJavaScriptCallFramePrototype.cpp:
1605         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1606         * runtime/ArrayConstructor.cpp:
1607         (JSC::ArrayConstructor::finishCreation):
1608         * runtime/AsyncFunctionConstructor.cpp:
1609         (JSC::AsyncFunctionConstructor::finishCreation):
1610         * runtime/AsyncGeneratorFunctionConstructor.cpp:
1611         (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
1612         * runtime/BigIntConstructor.cpp:
1613         (JSC::BigIntConstructor::finishCreation):
1614         * runtime/BooleanConstructor.cpp:
1615         (JSC::BooleanConstructor::finishCreation):
1616         * runtime/DateConstructor.cpp:
1617         (JSC::DateConstructor::finishCreation):
1618         * runtime/ErrorConstructor.cpp:
1619         (JSC::ErrorConstructor::finishCreation):
1620         * runtime/FunctionConstructor.cpp:
1621         (JSC::FunctionConstructor::finishCreation):
1622         * runtime/FunctionPrototype.cpp:
1623         (JSC::FunctionPrototype::finishCreation):
1624         (JSC::FunctionPrototype::addFunctionProperties):
1625         (JSC::FunctionPrototype::initRestrictedProperties):
1626         * runtime/FunctionPrototype.h:
1627         * runtime/GeneratorFunctionConstructor.cpp:
1628         (JSC::GeneratorFunctionConstructor::finishCreation):
1629         * runtime/InternalFunction.cpp:
1630         (JSC::InternalFunction::finishCreation):
1631         * runtime/InternalFunction.h:
1632         * runtime/IntlCollatorConstructor.cpp:
1633         (JSC::IntlCollatorConstructor::finishCreation):
1634         * runtime/IntlDateTimeFormatConstructor.cpp:
1635         (JSC::IntlDateTimeFormatConstructor::finishCreation):
1636         * runtime/IntlNumberFormatConstructor.cpp:
1637         (JSC::IntlNumberFormatConstructor::finishCreation):
1638         * runtime/IntlPluralRulesConstructor.cpp:
1639         (JSC::IntlPluralRulesConstructor::finishCreation):
1640         * runtime/JSArrayBufferConstructor.cpp:
1641         (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
1642         * runtime/JSArrayBufferPrototype.cpp:
1643         (JSC::JSArrayBufferPrototype::finishCreation):
1644         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1645         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1646         * runtime/JSGlobalObject.cpp:
1647         (JSC::JSGlobalObject::init):
1648         * runtime/JSObject.cpp:
1649         (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
1650         (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
1651         * runtime/JSObject.h:
1652         * runtime/JSPromiseConstructor.cpp:
1653         (JSC::JSPromiseConstructor::finishCreation):
1654         * runtime/JSTypedArrayViewConstructor.cpp:
1655         (JSC::JSTypedArrayViewConstructor::finishCreation):
1656         * runtime/JSTypedArrayViewPrototype.cpp:
1657         (JSC::JSTypedArrayViewPrototype::finishCreation):
1658         * runtime/MapConstructor.cpp:
1659         (JSC::MapConstructor::finishCreation):
1660         * runtime/MapPrototype.cpp:
1661         (JSC::MapPrototype::finishCreation):
1662         * runtime/NativeErrorConstructor.cpp:
1663         (JSC::NativeErrorConstructorBase::finishCreation):
1664         * runtime/NullGetterFunction.h:
1665         * runtime/NullSetterFunction.h:
1666         * runtime/NumberConstructor.cpp:
1667         (JSC::NumberConstructor::finishCreation):
1668         * runtime/ObjectConstructor.cpp:
1669         (JSC::ObjectConstructor::finishCreation):
1670         * runtime/ProxyConstructor.cpp:
1671         (JSC::ProxyConstructor::finishCreation):
1672         * runtime/RegExpConstructor.cpp:
1673         (JSC::RegExpConstructor::finishCreation):
1674         * runtime/RegExpPrototype.cpp:
1675         (JSC::RegExpPrototype::finishCreation):
1676         * runtime/SetConstructor.cpp:
1677         (JSC::SetConstructor::finishCreation):
1678         * runtime/SetPrototype.cpp:
1679         (JSC::SetPrototype::finishCreation):
1680         * runtime/StringConstructor.cpp:
1681         (JSC::StringConstructor::finishCreation):
1682         * runtime/SymbolConstructor.cpp:
1683         (JSC::SymbolConstructor::finishCreation):
1684         * runtime/WeakMapConstructor.cpp:
1685         (JSC::WeakMapConstructor::finishCreation):
1686         * runtime/WeakSetConstructor.cpp:
1687         (JSC::WeakSetConstructor::finishCreation):
1688         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1689         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
1690         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1691         (JSC::WebAssemblyInstanceConstructor::finishCreation):
1692         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
1693         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
1694         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1695         (JSC::WebAssemblyMemoryConstructor::finishCreation):
1696         * wasm/js/WebAssemblyModuleConstructor.cpp:
1697         (JSC::WebAssemblyModuleConstructor::finishCreation):
1698         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1699         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
1700         * wasm/js/WebAssemblyTableConstructor.cpp:
1701         (JSC::WebAssemblyTableConstructor::finishCreation):
1702
1703 2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
1704
1705         op_check_tdz does not def its argument
1706         https://bugs.webkit.org/show_bug.cgi?id=192880
1707         <rdar://problem/46221598>
1708
1709         Reviewed by Saam Barati.
1710
1711         This prevented the for-in loop optimization in the bytecode generator, since
1712         the analysis sees a redefinition of the loop variable.
1713
1714         * bytecode/BytecodeUseDef.h:
1715         (JSC::computeDefsForBytecodeOffset):
1716
1717 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
1718
1719         [JSC] Make more fields lazy in JSGlobalObject
1720         https://bugs.webkit.org/show_bug.cgi?id=195449
1721
1722         Reviewed by Mark Lam.
1723
1724         This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
1725
1726         1. Some minor structures like moduleRecordStructure.
1727         2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
1728         3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
1729
1730         * interpreter/Interpreter.cpp:
1731         (JSC::Interpreter::execute):
1732         * runtime/JSArrayBufferPrototype.h:
1733         * runtime/JSGlobalObject.cpp:
1734         (JSC::JSGlobalObject::init):
1735         (JSC::JSGlobalObject::visitChildren):
1736         * runtime/JSGlobalObject.h:
1737         (JSC::JSGlobalObject::parseIntFunction const):
1738         (JSC::JSGlobalObject::parseFloatFunction const):
1739         (JSC::JSGlobalObject::evalFunction const):
1740         (JSC::JSGlobalObject::strictEvalActivationStructure const):
1741         (JSC::JSGlobalObject::moduleRecordStructure const):
1742         (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
1743         (JSC::JSGlobalObject::proxyObjectStructure const):
1744         (JSC::JSGlobalObject::callableProxyObjectStructure const):
1745         (JSC::JSGlobalObject::proxyRevokeStructure const):
1746         (JSC::JSGlobalObject::arrayBufferConstructor const):
1747         (JSC::JSGlobalObject::arrayBufferPrototype const):
1748         (JSC::JSGlobalObject::arrayBufferStructure const):
1749         * runtime/ProxyObject.h:
1750         * runtime/StrictEvalActivation.cpp:
1751         (JSC::StrictEvalActivation::StrictEvalActivation):
1752         * runtime/StrictEvalActivation.h:
1753         * wasm/js/JSWebAssemblyMemory.cpp:
1754         (JSC::JSWebAssemblyMemory::buffer):
1755         * wasm/js/WebAssemblyModuleConstructor.cpp:
1756         (JSC::webAssemblyModuleCustomSections):
1757
1758 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
1759
1760         [JSC] Remove merging must handle values into proven types in CFA
1761         https://bugs.webkit.org/show_bug.cgi?id=195444
1762
1763         Reviewed by Saam Barati.
1764
1765         Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
1766         from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
1767
1768             Block #2 (loop header) succ #3, #4
1769             ...
1770             1: ForceOSRExit
1771             ...
1772             2: JSConstant(0)
1773             3: SetLocal(@2, loc6)
1774             ...
1775             4: Branch(#3, #4)
1776
1777             Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
1778             ...
1779             5: GetLocal(loc6)
1780             6: StringFromCharCode(@5)
1781             ...
1782
1783         Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
1784         If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
1785         as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
1786         we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
1787         we should not merge it in CFA.
1788
1789         Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
1790         progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
1791
1792         * dfg/DFGCFAPhase.cpp:
1793         (JSC::DFG::CFAPhase::run):
1794         (JSC::DFG::CFAPhase::performBlockCFA):
1795         (JSC::DFG::CFAPhase::injectOSR): Deleted.
1796
1797 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
1798
1799         [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
1800         https://bugs.webkit.org/show_bug.cgi?id=195429
1801
1802         Reviewed by Saam Barati.
1803
1804         We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
1805         for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
1806         this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
1807         Note that ThunkGenerators's StringFromCharCode thunk was correct.
1808
1809         * dfg/DFGSpeculativeJIT.cpp:
1810         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
1811         * ftl/FTLLowerDFGToB3.cpp:
1812         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
1813
1814 2019-03-07  Mark Lam  <mark.lam@apple.com>
1815
1816         Follow up refactoring in try-finally code after r242591.
1817         https://bugs.webkit.org/show_bug.cgi?id=195428
1818
1819         Reviewed by Saam Barati.
1820
1821         1. Added some comments in emitFinallyCompletion() to describe each completion case.
1822         2. Converted CatchEntry into a struct.
1823         3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
1824            to be more clear about its purpose.
1825
1826         * bytecompiler/BytecodeGenerator.cpp:
1827         (JSC::BytecodeGenerator::generate):
1828         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
1829         (JSC::BytecodeGenerator::emitFinallyCompletion):
1830         * bytecompiler/BytecodeGenerator.h:
1831
1832 2019-03-07  Saam Barati  <sbarati@apple.com>
1833
1834         CompactVariableMap::Handle's copy operator= leaks the previous data
1835         https://bugs.webkit.org/show_bug.cgi?id=195398
1836
1837         Reviewed by Yusuke Suzuki.
1838
1839         The copy constructor was just assigning |this| to the new value,
1840         forgetting to decrement the ref count of the thing pointed to by
1841         the |this| handle. Based on Yusuke's suggestion, this patch refactors
1842         the move constructor, move operator=, and copy operator= to use the
1843         swap() primitive and the copy constructor primitive.
1844
1845         * parser/VariableEnvironment.cpp:
1846         (JSC::CompactVariableMap::Handle::Handle):
1847         (JSC::CompactVariableMap::Handle::swap):
1848         (JSC::CompactVariableMap::Handle::operator=): Deleted.
1849         * parser/VariableEnvironment.h:
1850         (JSC::CompactVariableMap::Handle::Handle):
1851         (JSC::CompactVariableMap::Handle::operator=):
1852
1853 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
1854
1855         Lazily decode cached bytecode
1856         https://bugs.webkit.org/show_bug.cgi?id=194810
1857
1858         Reviewed by Saam Barati.
1859
1860         Like lazy parsing, we should pause at code block boundaries. Instead
1861         of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
1862         we store their offsets in the executable and lazily decode them on the next
1863         call to `unlinkedCodeBlockFor`.
1864
1865         * bytecode/UnlinkedFunctionExecutable.cpp:
1866         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1867         (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
1868         (JSC::UnlinkedFunctionExecutable::visitChildren):
1869         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1870         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
1871         * bytecode/UnlinkedFunctionExecutable.h:
1872         * runtime/CachedTypes.cpp:
1873         (JSC::Decoder::Decoder):
1874         (JSC::Decoder::~Decoder):
1875         (JSC::Decoder::create):
1876         (JSC::Decoder::offsetOf):
1877         (JSC::Decoder::cacheOffset):
1878         (JSC::Decoder::ptrForOffsetFromBase):
1879         (JSC::Decoder::handleForEnvironment const):
1880         (JSC::Decoder::setHandleForEnvironment):
1881         (JSC::Decoder::addFinalizer):
1882         (JSC::VariableLengthObject::isEmpty const):
1883         (JSC::CachedWriteBarrier::isEmpty const):
1884         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
1885         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
1886         (JSC::CachedFunctionExecutable::decode const):
1887         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1888         (JSC::decodeCodeBlockImpl):
1889         (JSC::isCachedBytecodeStillValid):
1890         (JSC::decodeFunctionCodeBlock):
1891         * runtime/CachedTypes.h:
1892         (JSC::Decoder::vm):
1893
1894 2019-03-06  Mark Lam  <mark.lam@apple.com>
1895
1896         Exception is a JSCell, not a JSObject.
1897         https://bugs.webkit.org/show_bug.cgi?id=195392
1898
1899         Reviewed by Saam Barati.
1900
1901         Exception is a VM implementation construct to carry a stack trace for the point
1902         where it is thrown from.  As a reminder, an Exception is needed because:
1903         1. JS code can throw primitives as well that are non-cells.
1904         2. Error objects capture the stack trace at the point where they are constructed,
1905            which is not always the same as the point where they are thrown (if they are
1906            thrown).
1907
1908         Hence, Exception should not be visible to JS code, and therefore should not be a
1909         JSObject.  Hence, it should not inherit from JSDestructibleObject.
1910
1911         This patch changes the following:
1912
1913         1. Exception now inherits directly from JSCell instead.
1914
1915         2. Places where we return an Exception masquerading as a JSObject* are now
1916            updated to return a nullptr when we encounter an exception.
1917
1918         3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
1919            exception in functions that return JSValue or EncodedJSValue.  This is because
1920            the number that implements the following pattern is too numerous:
1921
1922                 return throw<Some Error>(...)
1923
1924            We'll leave these as is for now.
1925
1926         * bytecode/CodeBlock.h:
1927         (JSC::ScriptExecutable::prepareForExecution):
1928         * interpreter/Interpreter.cpp:
1929         (JSC::Interpreter::executeProgram):
1930         (JSC::Interpreter::executeCall):
1931         (JSC::Interpreter::executeConstruct):
1932         (JSC::Interpreter::prepareForRepeatCall):
1933         (JSC::Interpreter::execute):
1934         (JSC::Interpreter::executeModuleProgram):
1935         * jit/JITOperations.cpp:
1936         * llint/LLIntSlowPaths.cpp:
1937         (JSC::LLInt::setUpCall):
1938         * runtime/ConstructData.cpp:
1939         (JSC::construct):
1940         * runtime/Error.cpp:
1941         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
1942         (JSC::throwTypeError):
1943         (JSC::throwSyntaxError):
1944         * runtime/Error.h:
1945         (JSC::throwRangeError):
1946         * runtime/Exception.cpp:
1947         (JSC::Exception::createStructure):
1948         * runtime/Exception.h:
1949         * runtime/ExceptionHelpers.cpp:
1950         (JSC::throwOutOfMemoryError):
1951         (JSC::throwStackOverflowError):
1952         (JSC::throwTerminatedExecutionException):
1953         * runtime/ExceptionHelpers.h:
1954         * runtime/FunctionConstructor.cpp:
1955         (JSC::constructFunction):
1956         (JSC::constructFunctionSkippingEvalEnabledCheck):
1957         * runtime/IntlPluralRules.cpp:
1958         (JSC::IntlPluralRules::resolvedOptions):
1959         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1960         (JSC::constructGenericTypedArrayViewWithArguments):
1961         * runtime/JSObject.h:
1962         * runtime/ObjectConstructor.cpp:
1963         (JSC::objectConstructorSeal):
1964         (JSC::objectConstructorFreeze):
1965         * runtime/ProgramExecutable.cpp:
1966         (JSC::ProgramExecutable::initializeGlobalProperties):
1967         * runtime/RegExpConstructor.cpp:
1968         (JSC::regExpCreate):
1969         (JSC::constructRegExp):
1970         * runtime/ScriptExecutable.cpp:
1971         (JSC::ScriptExecutable::newCodeBlockFor):
1972         (JSC::ScriptExecutable::prepareForExecutionImpl):
1973         * runtime/ScriptExecutable.h:
1974         * runtime/ThrowScope.cpp:
1975         (JSC::ThrowScope::throwException):
1976         * runtime/ThrowScope.h:
1977         (JSC::ThrowScope::throwException):
1978         (JSC::throwException):
1979         * runtime/VM.cpp:
1980         (JSC::VM::throwException):
1981         * runtime/VM.h:
1982
1983 2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
1984
1985         [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
1986         https://bugs.webkit.org/show_bug.cgi?id=195346
1987
1988         Reviewed by Fujii Hironori.
1989
1990         * jsc.cpp:
1991         (currentWorkingDirectory):
1992         (fetchModuleFromLocalFileSystem):
1993         * runtime/DateConversion.cpp:
1994         (JSC::formatDateTime):
1995         Use wchar helpers as needed.
1996
1997 2019-03-06  Mark Lam  <mark.lam@apple.com>
1998
1999         Fix incorrect handling of try-finally completion values.
2000         https://bugs.webkit.org/show_bug.cgi?id=195131
2001         <rdar://problem/46222079>
2002
2003         Reviewed by Saam Barati and Yusuke Suzuki.
2004
2005         Consider the following:
2006
2007             function foo() {                        // line 1
2008                 try {
2009                     return 42;                      // line 3
2010                 } finally {
2011                     for (var j = 0; j < 1; j++) {   // line 5
2012                         try {
2013                             throw '';               // line 7
2014                         } finally {
2015                             continue;               // line 9
2016                         }
2017                     }
2018                 }                                   // line 11
2019             }
2020             var result = foo();
2021
2022         With the current (before fix) code base, result will be the exception object thrown
2023         at line 7.  The expected result should be 42, returned at line 3.
2024
2025         The bug is that we were previously only using one set of completion type and
2026         value registers for the entire function.  This is inadequate because the outer
2027         try-finally needs to preserve its own completion type and value ({ Return, 42 }
2028         in this case) in order to be able to complete correctly.
2029
2030         One might be deceived into thinking that the above example should complete with
2031         the exception thrown at line 7.  However, according to Section 13.15.8 of the
2032         ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
2033         completion.  As a result, it overrides the throw from line 7.  After the continue,
2034         execution resumes at the top of the loop at line 5, followed by a normal completion
2035         at line 11.
2036
2037         Also according to Section 13.15.8, given that the completion type of the outer
2038         finally is normal, the resultant completion of the outer try-finally should be
2039         the completion of the outer try block i.e. { Return, 42 }.
2040
2041         This patch makes the following changes:
2042         
2043         1. Fix handling of finally completion to use a unique set of completion
2044            type and value registers for each FinallyContext.
2045
2046         2. Move the setting of Throw completion type to the out of line exception handler.
2047            This makes the mainline code slightly less branchy.
2048
2049         3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
2050            emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
2051            bytecode inline.  Also, these make it clearer when we're emitting a handler
2052            for a catch vs a finally.
2053
2054         4. Allocate the FinallyContext on the stack instead of as a member of the
2055            heap allocated ControlFlowScope.  This simplifies its life-cycle management
2056            and reduces the amount of needed copying.
2057
2058         5. Update emitFinallyCompletion() to propagate the completion type and value to
2059            the outer FinallyContext when needed.
2060
2061         6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
2062            only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
2063            wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
2064            the order needs to be corrected.
2065
2066         7. Remove the unused CompletionType::Break and Continue.  These are encoded with
2067            the jumpIDs of the jump targets instead.
2068
2069         Relevant specifications:
2070         Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
2071         Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
2072
2073         * bytecompiler/BytecodeGenerator.cpp:
2074         (JSC::FinallyContext::FinallyContext):
2075         (JSC::BytecodeGenerator::generate):
2076         (JSC::BytecodeGenerator::BytecodeGenerator):
2077         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2078         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2079         (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
2080         (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
2081         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
2082         (JSC::BytecodeGenerator::emitEnumeration):
2083         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2084         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2085         (JSC::BytecodeGenerator::emitFinallyCompletion):
2086         (JSC::BytecodeGenerator::emitJumpIf):
2087         (JSC::BytecodeGenerator::emitCatch): Deleted.
2088         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
2089         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
2090         * bytecompiler/BytecodeGenerator.h:
2091         (JSC::FinallyContext::completionTypeRegister const):
2092         (JSC::FinallyContext::completionValueRegister const):
2093         (JSC::ControlFlowScope::ControlFlowScope):
2094         (JSC::BytecodeGenerator::emitLoad):
2095         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
2096         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
2097         (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
2098         (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
2099         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
2100         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
2101         * bytecompiler/NodesCodegen.cpp:
2102         (JSC::TryNode::emitBytecode):
2103
2104 2019-03-06  Saam Barati  <sbarati@apple.com>
2105
2106         JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
2107         https://bugs.webkit.org/show_bug.cgi?id=195186
2108
2109         Reviewed by Keith Miller.
2110
2111         This patch makes it so that JSScript will keep its bytecode cache file
2112         locked as long as the JSScript is alive. This makes it obvious that it's
2113         safe to update that file, as it will only be used in a single VM, across
2114         all processes, at a single time. We may be able to extend this in the future
2115         if we can atomically update it across VMs/processes. However, we're choosing
2116         more restricted semantics now as it's always easier to extend these semantics
2117         in the future opposed to having to support the more flexible behavior
2118         up front.
2119         
2120         This patch also:
2121         - Adds error messages if writing the cache fails. We don't expect this to
2122           fail, but previously we would say we cached it even if write() fails.
2123         - Removes the unused m_moduleKey field.
2124         - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
2125           In the future, we should extend this to just fill in the parts of the cache
2126           that are not present. But we don't have the ability to do that yet, so we
2127           just result in an error for now.
2128
2129         * API/JSScript.mm:
2130         (-[JSScript dealloc]):
2131         (-[JSScript readCache]):
2132         (-[JSScript init]):
2133         (-[JSScript writeCache:]):
2134         * API/JSScriptInternal.h:
2135         * API/tests/testapi.mm:
2136         (testCacheFileIsExclusive):
2137         (testCacheFileFailsWhenItsAlreadyCached):
2138         (testObjectiveCAPI):
2139
2140 2019-03-06  Christopher Reid  <chris.reid@sony.com>
2141
2142         Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
2143         https://bugs.webkit.org/show_bug.cgi?id=195381
2144
2145         Reviewed by Mark Lam.
2146
2147         Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
2148         Also using `= { }` for struct initialization instead of memeset.
2149
2150         * inspector/remote/RemoteConnectionToTarget.cpp:
2151         * inspector/remote/RemoteInspector.cpp:
2152         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
2153         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2154         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
2155         * inspector/remote/glib/RemoteInspectorGlib.cpp:
2156         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
2157         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
2158         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
2159         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
2160
2161 2019-03-06  Saam Barati  <sbarati@apple.com>
2162
2163         Air::reportUsedRegisters must padInterference
2164         https://bugs.webkit.org/show_bug.cgi?id=195303
2165         <rdar://problem/48270343>
2166
2167         Reviewed by Keith Miller.
2168
2169         reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
2170         registers. However, liveness can report incorrect results in certain 
2171         scenarios when considering liveness at instruction boundaries. For example,
2172         it can go wrong when an Inst has a LateUse of a register and the following
2173         Inst has an EarlyDef of that same register. Such a scenario could lead us
2174         to incorrectly say the register is not live-in to the first Inst. Pad
2175         interference inserts Nops between such instruction boundaries that cause
2176         this issue.
2177         
2178         The test with this patch fixes the issue in reportUsedRegisters. This patch
2179         also conservatively makes it so that lowerAfterRegAlloc calls padInterference
2180         since it also reasons about liveness.
2181
2182         * b3/air/AirLowerAfterRegAlloc.cpp:
2183         (JSC::B3::Air::lowerAfterRegAlloc):
2184         * b3/air/AirPadInterference.h:
2185         * b3/air/AirReportUsedRegisters.cpp:
2186         (JSC::B3::Air::reportUsedRegisters):
2187         * b3/testb3.cpp:
2188         (JSC::B3::testReportUsedRegistersLateUseNotDead):
2189         (JSC::B3::run):
2190
2191 2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
2192
2193         [JSC] AI should not propagate AbstractValue relying on constant folding phase
2194         https://bugs.webkit.org/show_bug.cgi?id=195375
2195
2196         Reviewed by Saam Barati.
2197
2198         MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
2199         This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
2200         and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
2201         proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
2202         at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
2203         relying on constant folding phase.
2204
2205         * dfg/DFGAbstractInterpreterInlines.h:
2206         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2207
2208 2019-03-05  Saam barati  <sbarati@apple.com>
2209
2210         op_switch_char broken for rope strings after JSRopeString layout rewrite
2211         https://bugs.webkit.org/show_bug.cgi?id=195339
2212         <rdar://problem/48592545>
2213
2214         Reviewed by Yusuke Suzuki.
2215
2216         When we did the JSString rewrite, we accidentally broke LLInt's switch_char
2217         for rope strings. That change made it so that we always go to the slow path
2218         for ropes. That's wrong. The slow path should only be taken when the rope
2219         is of length 1. For lengths other than 1, we need to fall through to the
2220         default case. This patch fixes this.
2221
2222         * llint/LowLevelInterpreter32_64.asm:
2223         * llint/LowLevelInterpreter64.asm:
2224         * runtime/JSString.h:
2225
2226 2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
2227
2228         [JSC] Should check exception for JSString::toExistingAtomicString
2229         https://bugs.webkit.org/show_bug.cgi?id=195337
2230
2231         Reviewed by Keith Miller, Saam Barati, and Mark Lam.
2232
2233         We missed the exception check for JSString::toExistingAtomicString while it can resolve
2234         a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
2235         fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
2236
2237         * dfg/DFGOperations.cpp:
2238         * jit/JITOperations.cpp:
2239         (JSC::getByVal):
2240         * llint/LLIntSlowPaths.cpp:
2241         (JSC::LLInt::getByVal):
2242         * runtime/CommonSlowPaths.cpp:
2243         (JSC::SLOW_PATH_DECL):
2244
2245 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2246
2247         Unreviewed, build fix for debug builds after r242397
2248
2249         * runtime/JSString.h:
2250
2251 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2252
2253         [JSC] Store bits for JSRopeString in 3 stores
2254         https://bugs.webkit.org/show_bug.cgi?id=195234
2255
2256         Reviewed by Saam Barati.
2257
2258         This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
2259         Previously, we store some part of data separately. Instead, this patch calculates
2260         the data first by bit operations and store calculated data with fewer stores.
2261
2262         This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
2263         of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
2264         we can put them into the lower 3 bits, they are always empty due to alignment.
2265
2266         * bytecode/AccessCase.cpp:
2267         (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
2268         * dfg/DFGSpeculativeJIT.cpp:
2269         (JSC::DFG::SpeculativeJIT::canBeRope):
2270         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2271         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2272         * dfg/DFGSpeculativeJIT.h:
2273         * ftl/FTLAbstractHeapRepository.cpp:
2274         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
2275         * ftl/FTLAbstractHeapRepository.h:
2276         * ftl/FTLLowerDFGToB3.cpp:
2277         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
2278         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
2279         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
2280         * runtime/JSString.cpp:
2281         (JSC::JSString::visitChildren):
2282         * runtime/JSString.h:
2283         (JSC::JSString::is8Bit const):
2284         (JSC::JSString::isSubstring const):
2285         * tools/JSDollarVM.cpp:
2286         (JSC::functionCreateNullRopeString):
2287         (JSC::JSDollarVM::finishCreation):
2288
2289 2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
2290
2291         ITMLKit Inspector: Data Bindings / Associated Data for nodes
2292         https://bugs.webkit.org/show_bug.cgi?id=195290
2293         <rdar://problem/48304019>
2294
2295         Reviewed by Devin Rousso.
2296
2297         * inspector/protocol/DOM.json:
2298
2299 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2300
2301         [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
2302         https://bugs.webkit.org/show_bug.cgi?id=195250
2303
2304         Reviewed by Saam Barati.
2305
2306         By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
2307         We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
2308
2309         We also remove m_intlObject field from JSGlobalObject since we no longer use it.
2310
2311         * builtins/BuiltinNames.h:
2312         * builtins/GlobalOperations.js:
2313         (globalPrivate.copyDataProperties):
2314         (globalPrivate.copyDataPropertiesNoExclusions):
2315         * runtime/JSGlobalObject.cpp:
2316         (JSC::createReflectProperty):
2317         (JSC::JSGlobalObject::init):
2318         (JSC::JSGlobalObject::visitChildren):
2319         * runtime/JSGlobalObject.h:
2320         * runtime/ObjectConstructor.cpp:
2321         (JSC::ObjectConstructor::finishCreation):
2322         (JSC::objectConstructorOwnKeys):
2323         * runtime/ReflectObject.cpp:
2324         (JSC::ReflectObject::finishCreation):
2325
2326 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2327
2328         [JSC] Offer @makeTypeError instead of exposing @TypeError
2329         https://bugs.webkit.org/show_bug.cgi?id=193858
2330
2331         Reviewed by Mark Lam.
2332
2333         Instead of exposing @TypeError, we expose @makeTypeError function.
2334         And we make TypeError and Error lazily-allocated objects in non JIT environment.
2335         In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
2336         touch Error prototype anyway. But we can make them lazy in a subsequent patch.
2337
2338         * builtins/AsyncFromSyncIteratorPrototype.js:
2339         * builtins/AsyncGeneratorPrototype.js:
2340         (globalPrivate.asyncGeneratorEnqueue):
2341         * builtins/BuiltinNames.h:
2342         * builtins/PromiseOperations.js:
2343         (globalPrivate.createResolvingFunctions.resolve):
2344         * runtime/JSGlobalObject.cpp:
2345         (JSC::JSGlobalObject::initializeErrorConstructor):
2346         (JSC::JSGlobalObject::init):
2347         (JSC::JSGlobalObject::visitChildren):
2348         * runtime/JSGlobalObject.h:
2349         (JSC::JSGlobalObject::errorPrototype const):
2350         (JSC::JSGlobalObject::errorStructure const):
2351         * runtime/JSGlobalObjectFunctions.cpp:
2352         (JSC::globalFuncMakeTypeError):
2353         * runtime/JSGlobalObjectFunctions.h:
2354
2355 2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>
2356
2357         [GLib] Returning G_TYPE_OBJECT from a constructor does not work
2358         https://bugs.webkit.org/show_bug.cgi?id=195206
2359
2360         Reviewed by Žan Doberšek.
2361
2362         We are freeing the newly created object before returning from the constructor.
2363
2364         * API/glib/JSCCallbackFunction.cpp:
2365         (JSC::JSCCallbackFunction::construct):
2366
2367 2019-03-02  Darin Adler  <darin@apple.com>
2368
2369         Retire legacy dtoa function and DecimalNumber class
2370         https://bugs.webkit.org/show_bug.cgi?id=195253
2371
2372         Reviewed by Daniel Bates.
2373
2374         * runtime/NumberPrototype.cpp:
2375         (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
2376         using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
2377
2378 2019-03-01  Darin Adler  <darin@apple.com>
2379
2380         Finish removing String::format
2381         https://bugs.webkit.org/show_bug.cgi?id=194893
2382
2383         Reviewed by Daniel Bates.
2384
2385         * bytecode/CodeBlock.cpp:
2386         (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
2387         using the new "pad" function.
2388
2389 2019-03-01  Christopher Reid  <chris.reid@sony.com>
2390
2391         [PlayStation] Upstream playstation's remote inspector server
2392         https://bugs.webkit.org/show_bug.cgi?id=193806
2393
2394         Reviewed by Joseph Pecoraro.
2395
2396         Upstreaming PlayStation's Remote Inspector implementation.
2397         It is using a JSON RPC protocol over TCP sockets.
2398         This inspector implementation is planned to also support running on a WinCairo Client and Server.
2399
2400         * PlatformPlayStation.cmake:
2401         * SourcesGTK.txt:
2402         * SourcesWPE.txt:
2403         * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
2404         * inspector/remote/RemoteInspector.h:
2405         * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
2406         * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
2407         * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
2408         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
2409         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
2410         * inspector/remote/playstation/RemoteInspectorServer.h: Added.
2411         * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
2412         * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
2413         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
2414         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
2415         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
2416         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
2417         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
2418
2419 2019-03-01  Saam Barati  <sbarati@apple.com>
2420
2421         Create SPI to crash if a JSC VM is created
2422         https://bugs.webkit.org/show_bug.cgi?id=195231
2423         <rdar://problem/47717990>
2424
2425         Reviewed by Mark Lam.
2426
2427         * API/JSVirtualMachine.mm:
2428         (+[JSVirtualMachine setCrashOnVMCreation:]):
2429         * API/JSVirtualMachinePrivate.h:
2430         * runtime/VM.cpp:
2431         (JSC::VM::VM):
2432         (JSC::VM::setCrashOnVMCreation):
2433         * runtime/VM.h:
2434
2435 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
2436
2437         [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
2438         https://bugs.webkit.org/show_bug.cgi?id=195235
2439
2440         Reviewed by Saam Barati.
2441
2442         This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
2443
2444         * runtime/JSString.h:
2445
2446 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
2447
2448         [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
2449         https://bugs.webkit.org/show_bug.cgi?id=195221
2450
2451         Reviewed by Mark Lam.
2452
2453         ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
2454         but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
2455
2456         * dfg/DFGSpeculativeJIT.cpp:
2457         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2458         * dfg/DFGSpeculativeJIT32_64.cpp:
2459         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
2460         * dfg/DFGSpeculativeJIT64.cpp:
2461         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
2462
2463 2019-03-01  Justin Fan  <justin_fan@apple.com>
2464
2465         [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
2466         https://bugs.webkit.org/show_bug.cgi?id=195191
2467
2468         Rubber-stamped by Dean Jackson.
2469
2470         Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
2471
2472         * Configurations/FeatureDefines.xcconfig:
2473
2474 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
2475
2476         Fix debug builds with GCC
2477         https://bugs.webkit.org/show_bug.cgi?id=195205
2478
2479         Unreviewed. Fix debug builds in GCC by removing
2480         the constexpr-keyword for this function.
2481
2482         * runtime/CachedTypes.cpp:
2483         (JSC::tagFromSourceCodeType):
2484
2485 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
2486
2487         [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
2488         https://bugs.webkit.org/show_bug.cgi?id=195164
2489
2490         Reviewed by Mark Lam.
2491
2492         Short branches in IT blocks are deprecated in AArch32. In addition the
2493         the conditional branch was the only instruction in the IT block. Short
2494         branches are able to encode the condition code themselves, the additional
2495         IT instruction is not needed.
2496
2497         The assembler was also warning that writing into APSR without a bitmask
2498         was deprecated. Therefore use APSR_nzcvq instead, this generates the same
2499         instruction encoding.
2500
2501         * assembler/MacroAssemblerARMv7.cpp:
2502
2503 2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>
2504
2505         Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
2506         https://bugs.webkit.org/show_bug.cgi?id=194999
2507
2508         Reviewed by Saam Barati.
2509
2510         These fields are unnecessary, since we can just check that m_offset
2511         has not been initialized (I added VariableLengthObject::isEmpty for
2512         that). They also add 7-byte padding to these classes, which is pretty
2513         bad given how frequently CachedPtr is used.
2514
2515         * runtime/CachedTypes.cpp:
2516         (JSC::CachedObject::operator new[]):
2517         (JSC::VariableLengthObject::allocate):
2518         (JSC::VariableLengthObject::isEmpty const):
2519         (JSC::CachedPtr::encode):
2520         (JSC::CachedPtr::decode const):
2521         (JSC::CachedPtr::get const):
2522         (JSC::CachedOptional::encode):
2523         (JSC::CachedOptional::decode const):
2524         (JSC::CachedOptional::decodeAsPtr const):
2525
2526 2019-02-28  Yusuke Suzuki  <ysuzuki@apple.com>
2527
2528         [JSC] sizeof(JSString) should be 16
2529         https://bugs.webkit.org/show_bug.cgi?id=194375
2530
2531         Reviewed by Saam Barati.
2532
2533         This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
2534         Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
2535
2536         JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
2537         information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
2538         We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
2539
2540         The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
2541         storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
2542         fibers to compress three fibers + length + flags into three pointer width storage.
2543
2544         In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
2545         JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
2546         place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
2547         encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
2548         are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
2549
2550         Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
2551         and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
2552         are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
2553         and we must not modify these part later.
2554
2555                      0                        8        10               16                       32                                     48
2556         JSString     [   ID      ][  header  ][   String pointer      0]
2557         JSRopeString [   ID      ][  header  ][ flags ][ 1st fiber    1][  length  ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
2558                                                                       ^
2559                                                                    isRope bit
2560
2561         Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
2562         To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
2563
2564         This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
2565         critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
2566         context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
2567         creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
2568         JSRopeString::RopeBuilder not to construct an empty JSRopeString.
2569
2570         This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
2571
2572         * JavaScriptCore.xcodeproj/project.pbxproj:
2573         * assembler/MacroAssemblerARM64.h:
2574         (JSC::MacroAssemblerARM64::storeZero16):
2575         * assembler/MacroAssemblerX86Common.h:
2576         (JSC::MacroAssemblerX86Common::storeZero16):
2577         (JSC::MacroAssemblerX86Common::store16):
2578         * bytecode/AccessCase.cpp:
2579         (JSC::AccessCase::generateImpl):
2580         * bytecode/InlineAccess.cpp:
2581         (JSC::InlineAccess::dumpCacheSizesAndCrash):
2582         (JSC::linkCodeInline):
2583         (JSC::InlineAccess::isCacheableStringLength):
2584         (JSC::InlineAccess::generateStringLength):
2585         * bytecode/InlineAccess.h:
2586         (JSC::InlineAccess::sizeForPropertyAccess):
2587         (JSC::InlineAccess::sizeForPropertyReplace):
2588         (JSC::InlineAccess::sizeForLengthAccess):
2589         * dfg/DFGOperations.cpp:
2590         * dfg/DFGOperations.h:
2591         * dfg/DFGSpeculativeJIT.cpp:
2592         (JSC::DFG::SpeculativeJIT::compileStringSlice):
2593         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
2594         (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
2595         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2596         (JSC::DFG::SpeculativeJIT::compileStringEquality):
2597         (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
2598         (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
2599         (JSC::DFG::SpeculativeJIT::emitStringBranch):
2600         (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
2601         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
2602         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2603         (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
2604         (JSC::DFG::SpeculativeJIT::compileArraySlice):
2605         (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
2606         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
2607         (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
2608         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
2609         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
2610         * dfg/DFGSpeculativeJIT.h:
2611         * dfg/DFGSpeculativeJIT32_64.cpp:
2612         (JSC::DFG::SpeculativeJIT::compile):
2613         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2614         * dfg/DFGSpeculativeJIT64.cpp:
2615         (JSC::DFG::SpeculativeJIT::compile):
2616         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2617         * ftl/FTLAbstractHeapRepository.cpp:
2618         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
2619         * ftl/FTLAbstractHeapRepository.h:
2620         * ftl/FTLLowerDFGToB3.cpp:
2621         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
2622         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
2623         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
2624         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2625         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
2626         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
2627         (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
2628         (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
2629         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
2630         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
2631         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
2632         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
2633         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
2634         (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
2635         (JSC::FTL::DFG::LowerDFGToB3::boolify):
2636         (JSC::FTL::DFG::LowerDFGToB3::switchString):
2637         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
2638         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
2639         (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
2640         * jit/AssemblyHelpers.cpp:
2641         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
2642         (JSC::AssemblyHelpers::branchIfValue):
2643         * jit/AssemblyHelpers.h:
2644         (JSC::AssemblyHelpers::branchIfRopeStringImpl):
2645         (JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
2646         * jit/JITInlines.h:
2647         (JSC::JIT::emitLoadCharacterString):
2648         * jit/Repatch.cpp:
2649         (JSC::tryCacheGetByID):
2650         * jit/ThunkGenerators.cpp:
2651         (JSC::stringGetByValGenerator):
2652         (JSC::stringCharLoad):
2653         * llint/LowLevelInterpreter.asm:
2654         * llint/LowLevelInterpreter32_64.asm:
2655         * llint/LowLevelInterpreter64.asm:
2656         * runtime/JSString.cpp:
2657         (JSC::JSString::createEmptyString):
2658         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
2659         (JSC::JSString::dumpToStream):
2660         (JSC::JSString::estimatedSize):
2661         (JSC::JSString::visitChildren):
2662         (JSC::JSRopeString::resolveRopeInternal8 const):
2663         (JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
2664         (JSC::JSRopeString::resolveRopeInternal16 const):
2665         (JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
2666         (JSC::JSRopeString::resolveRopeToAtomicString const):
2667         (JSC::JSRopeString::convertToNonRope const):
2668         (JSC::JSRopeString::resolveRopeToExistingAtomicString const):
2669         (JSC::JSRopeString::resolveRopeWithFunction const):
2670         (JSC::JSRopeString::resolveRope const):
2671         (JSC::JSRopeString::resolveRopeSlowCase8 const):
2672         (JSC::JSRopeString::resolveRopeSlowCase const):
2673         (JSC::JSRopeString::outOfMemory const):
2674         (JSC::JSRopeString::visitFibers): Deleted.
2675         (JSC::JSRopeString::clearFibers const): Deleted.
2676         * runtime/JSString.h:
2677         (JSC::JSString::uninitializedValueInternal const):
2678         (JSC::JSString::valueInternal const):
2679         (JSC::JSString::JSString):
2680         (JSC::JSString::finishCreation):
2681         (JSC::JSString::create):
2682         (JSC::JSString::offsetOfValue):
2683         (JSC::JSString::isRope const):
2684         (JSC::JSString::is8Bit const):
2685         (JSC::JSString::length const):
2686         (JSC::JSString::tryGetValueImpl const):
2687         (JSC::JSString::toAtomicString const):
2688         (JSC::JSString::toExistingAtomicString const):
2689         (JSC::JSString::value const):
2690         (JSC::JSString::tryGetValue const):
2691         (JSC::JSRopeString::unsafeView const):
2692         (JSC::JSRopeString::viewWithUnderlyingString const):
2693         (JSC::JSString::unsafeView const):
2694         (JSC::JSString::viewWithUnderlyingString const):
2695         (JSC::JSString::offsetOfLength): Deleted.
2696         (JSC::JSString::offsetOfFlags): Deleted.
2697         (JSC::JSString::setIs8Bit const): Deleted.
2698         (JSC::JSString::setLength): Deleted.
2699         (JSC::JSString::string): Deleted.
2700         (JSC::jsStringBuilder): Deleted.
2701         * runtime/JSStringInlines.h:
2702         (JSC::JSString::~JSString):
2703         (JSC::JSString::equal const):
2704         * runtime/ObjectPrototype.cpp:
2705         (JSC::objectProtoFuncToString):
2706         * runtime/RegExpMatchesArray.h:
2707         (JSC::createRegExpMatchesArray):
2708         * runtime/RegExpObjectInlines.h:
2709         (JSC::collectMatches):
2710         * runtime/RegExpPrototype.cpp:
2711         (JSC::regExpProtoFuncSplitFast):
2712         * runtime/SmallStrings.cpp:
2713         (JSC::SmallStrings::initializeCommonStrings):
2714         (JSC::SmallStrings::createEmptyString): Deleted.
2715         * runtime/SmallStrings.h:
2716         * runtime/StringPrototype.cpp:
2717         (JSC::stringProtoFuncSlice):
2718         * runtime/StringPrototypeInlines.h: Added.
2719         (JSC::stringSlice):
2720
2721 2019-02-28  Saam barati  <sbarati@apple.com>
2722
2723         Unreviewed. Attempt windows build fix after r242239.
2724
2725         * runtime/CachedTypes.cpp:
2726         (JSC::tagFromSourceCodeType):
2727
2728 2019-02-28  Mark Lam  <mark.lam@apple.com>
2729
2730         In cloop.rb, rename :int and :uint to :intptr and :uintptr.
2731         https://bugs.webkit.org/show_bug.cgi?id=195183
2732
2733         Reviewed by Yusuke Suzuki.
2734
2735         Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.
2736
2737         * offlineasm/cloop.rb:
2738
2739 2019-02-28  Saam barati  <sbarati@apple.com>
2740
2741         Make JSScript:cacheBytecodeWithError update the cache when the script changes
2742         https://bugs.webkit.org/show_bug.cgi?id=194912
2743
2744         Reviewed by Mark Lam.
2745
2746         Prior to this patch, the JSScript SPI would never check if its cached
2747         bytecode were still valid. This would lead the cacheBytecodeWithError
2748         succeeding even if the underlying cache were stale. This patch fixes
2749         that by making JSScript check if the cache is still valid. If it's not,
2750         we will cache bytecode when cacheBytecodeWithError is invoked.
2751
2752         * API/JSScript.mm:
2753         (-[JSScript readCache]):
2754         (-[JSScript writeCache:]):
2755         * API/tests/testapi.mm:
2756         (testBytecodeCacheWithSameCacheFileAndDifferentScript):
2757         (testObjectiveCAPI):
2758         * runtime/CachedTypes.cpp:
2759         (JSC::Decoder::Decoder):
2760         (JSC::VariableLengthObject::buffer const):
2761         (JSC::CachedPtr::decode const):
2762         (JSC::tagFromSourceCodeType):
2763         (JSC::GenericCacheEntry::isUpToDate const):
2764         (JSC::CacheEntry::isStillValid const):
2765         (JSC::GenericCacheEntry::decode const):
2766         (JSC::GenericCacheEntry::isStillValid const):
2767         (JSC::encodeCodeBlock):
2768         (JSC::decodeCodeBlockImpl):
2769         (JSC::isCachedBytecodeStillValid):
2770         * runtime/CachedTypes.h:
2771         * runtime/CodeCache.cpp:
2772         (JSC::sourceCodeKeyForSerializedBytecode):
2773         (JSC::sourceCodeKeyForSerializedProgram):
2774         (JSC::sourceCodeKeyForSerializedModule):
2775         (JSC::serializeBytecode):
2776         * runtime/CodeCache.h:
2777         (JSC::CodeCacheMap::fetchFromDiskImpl):
2778         * runtime/Completion.cpp:
2779         (JSC::generateProgramBytecode):
2780         (JSC::generateBytecode): Deleted.
2781         * runtime/Completion.h:
2782
2783 2019-02-28  Mark Lam  <mark.lam@apple.com>
2784
2785         cloop.rb shift mask should depend on the word size being shifted.
2786         https://bugs.webkit.org/show_bug.cgi?id=195181
2787         <rdar://problem/48484164>
2788
2789         Reviewed by Yusuke Suzuki.
2790
2791         Previously, we're always masking the shift amount with 0x1f.  This is only correct
2792         for 32-bit words.  For 64-bit words, the mask should be 0x3f.  For pointer sized
2793         shifts, the mask depends on sizeof(uintptr_t).
2794
2795         * offlineasm/cloop.rb:
2796
2797 2019-02-28  Justin Fan  <justin_fan@apple.com>
2798
2799         [Web GPU] Enable Web GPU only on 64-bit
2800         https://bugs.webkit.org/show_bug.cgi?id=195139
2801
2802         Because Metal is only supported on 64 bit apps.
2803
2804         Unreviewed build fix.
2805
2806         * Configurations/FeatureDefines.xcconfig:
2807
2808 2019-02-27  Mark Lam  <mark.lam@apple.com>
2809
2810         The parser is failing to record the token location of new in new.target.
2811         https://bugs.webkit.org/show_bug.cgi?id=195127
2812         <rdar://problem/39645578>
2813
2814         Reviewed by Yusuke Suzuki.
2815
2816         Also adjust the token location for the following to be as shown:
2817
2818             new.target
2819             ^
2820             super
2821             ^
2822             import.meta
2823             ^
2824
2825         * parser/Parser.cpp:
2826         (JSC::Parser<LexerType>::parseMemberExpression):
2827
2828 2019-02-27  Yusuke Suzuki  <ysuzuki@apple.com>
2829
2830         [JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
2831         https://bugs.webkit.org/show_bug.cgi?id=195144
2832         <rdar://problem/47595961>
2833
2834         Reviewed by Mark Lam.
2835
2836         DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
2837         locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
2838         to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
2839         At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
2840         DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
2841         in VariableAccessData.
2842
2843         This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
2844         And we skip handling dead mustHandleValue in DFG phases.
2845
2846         * bytecode/Operands.h:
2847         (JSC::Operands::isLocal const):
2848         (JSC::Operands::isVariable const): Deleted.
2849         * dfg/DFGCFAPhase.cpp:
2850         (JSC::DFG::CFAPhase::injectOSR):
2851         * dfg/DFGDriver.cpp:
2852         (JSC::DFG::compileImpl):
2853         (JSC::DFG::compile):
2854         * dfg/DFGDriver.h:
2855         * dfg/DFGJITCode.cpp:
2856         (JSC::DFG::JITCode::reconstruct):
2857         * dfg/DFGJITCode.h:
2858         * dfg/DFGOperations.cpp:
2859         * dfg/DFGPlan.cpp:
2860         (JSC::DFG::Plan::Plan):
2861         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2862         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
2863         * dfg/DFGPlan.h:
2864         (JSC::DFG::Plan::mustHandleValues const):
2865         * dfg/DFGPredictionInjectionPhase.cpp:
2866         (JSC::DFG::PredictionInjectionPhase::run):
2867         * dfg/DFGTypeCheckHoistingPhase.cpp:
2868         (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
2869         * ftl/FTLOSREntry.cpp:
2870         (JSC::FTL::prepareOSREntry):
2871         * jit/JITOperations.cpp:
2872
2873 2019-02-27  Simon Fraser  <simon.fraser@apple.com>
2874
2875         Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)
2876
2877         * bytecode/CodeBlock.cpp:
2878         (JSC::CodeBlock::nameForRegister):
2879
2880 2019-02-27  Robin Morisset  <rmorisset@apple.com>
2881
2882         DFG: Loop-invariant code motion (LICM) should not hoist dead code
2883         https://bugs.webkit.org/show_bug.cgi?id=194945
2884         <rdar://problem/48311657>
2885
2886         Reviewed by Saam Barati.
2887
2888         * dfg/DFGLICMPhase.cpp:
2889         (JSC::DFG::LICMPhase::run):
2890
2891 2019-02-27  Antoine Quint  <graouts@apple.com>
2892
2893         Support Pointer Events on macOS
2894         https://bugs.webkit.org/show_bug.cgi?id=195008
2895         <rdar://problem/47454419>
2896
2897         Reviewed by Dean Jackson.
2898
2899         * Configurations/FeatureDefines.xcconfig:
2900
2901 2019-02-26  Mark Lam  <mark.lam@apple.com>
2902
2903         Remove poisons in JSCPoison and uses of them.
2904         https://bugs.webkit.org/show_bug.cgi?id=195082
2905
2906         Reviewed by Yusuke Suzuki.
2907
2908         Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
2909         DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.
2910
2911         * API/JSAPIWrapperObject.h:
2912         (JSC::JSAPIWrapperObject::wrappedObject):
2913         * API/JSCallbackFunction.h:
2914         * API/JSCallbackObject.h:
2915         * API/glib/JSAPIWrapperGlobalObject.h:
2916         * CMakeLists.txt:
2917         * JavaScriptCore.xcodeproj/project.pbxproj:
2918         * Sources.txt:
2919         * bytecode/AccessCase.cpp:
2920         (JSC::AccessCase::generateWithGuard):
2921         * dfg/DFGSpeculativeJIT.cpp:
2922         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
2923         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2924         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2925         (JSC::DFG::SpeculativeJIT::compileGetExecutable):
2926         (JSC::DFG::SpeculativeJIT::compileCreateThis):
2927         * dfg/DFGSpeculativeJIT.h:
2928         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
2929         * ftl/FTLLowerDFGToB3.cpp:
2930         (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
2931         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
2932         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
2933         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2934         (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
2935         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
2936         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
2937         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
2938         (JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
2939         * ftl/FTLOutput.h:
2940         (JSC::FTL::Output::weakPoisonedPointer): Deleted.
2941         * jit/AssemblyHelpers.cpp:
2942         (JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
2943         (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
2944         (JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
2945         * jit/AssemblyHelpers.h:
2946         * jit/JITOpcodes.cpp:
2947         (JSC::JIT::emit_op_create_this):
2948         * jit/JITPropertyAccess.cpp:
2949         (JSC::JIT::emitScopedArgumentsGetByVal):
2950         * jit/Repatch.cpp:
2951         (JSC::linkPolymorphicCall):
2952         * jit/ThunkGenerators.cpp:
2953         (JSC::virtualThunkFor):
2954         (JSC::nativeForGenerator):
2955         (JSC::boundThisNoArgsFunctionCallGenerator):
2956         * parser/UnlinkedSourceCode.h:
2957         * runtime/ArrayPrototype.h:
2958         * runtime/CustomGetterSetter.h:
2959         (JSC::CustomGetterSetter::getter const):
2960         (JSC::CustomGetterSetter::setter const):
2961         * runtime/InitializeThreading.cpp:
2962         (JSC::initializeThreading):
2963         * runtime/InternalFunction.cpp:
2964         (JSC::InternalFunction::getCallData):
2965         (JSC::InternalFunction::getConstructData):
2966         * runtime/InternalFunction.h:
2967         (JSC::InternalFunction::nativeFunctionFor):
2968         * runtime/JSArrayBuffer.h:
2969         * runtime/JSBoundFunction.h:
2970         * runtime/JSCPoison.cpp: Removed.
2971         * runtime/JSCPoison.h: Removed.
2972         * runtime/JSFunction.h:
2973         * runtime/JSGlobalObject.h:
2974         * runtime/JSScriptFetchParameters.h:
2975         * runtime/JSScriptFetcher.h:
2976         * runtime/JSString.h:
2977         * runtime/NativeExecutable.cpp:
2978         (JSC::NativeExecutable::hashFor const):
2979         * runtime/NativeExecutable.h:
2980         * runtime/Options.h:
2981         * runtime/ScopedArguments.h:
2982         * runtime/Structure.cpp:
2983         (JSC::StructureTransitionTable::setSingleTransition):
2984         * runtime/StructureTransitionTable.h:
2985         (JSC::StructureTransitionTable::map const):
2986         (JSC::StructureTransitionTable::weakImpl const):
2987         (JSC::StructureTransitionTable::setMap):
2988         * runtime/WriteBarrier.h:
2989         * wasm/WasmB3IRGenerator.cpp:
2990         * wasm/WasmInstance.h:
2991         * wasm/js/JSToWasm.cpp:
2992         (JSC::Wasm::createJSToWasmWrapper):
2993         * wasm/js/JSWebAssemblyCodeBlock.h:
2994         * wasm/js/JSWebAssemblyInstance.cpp:
2995         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2996         (JSC::JSWebAssemblyInstance::visitChildren):
2997         * wasm/js/JSWebAssemblyInstance.h:
2998         * wasm/js/JSWebAssemblyMemory.h:
2999         * wasm/js/JSWebAssemblyModule.h:
3000         * wasm/js/JSWebAssemblyTable.cpp:
3001         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
3002         (JSC::JSWebAssemblyTable::grow):
3003         (JSC::JSWebAssemblyTable::clearFunction):
3004         * wasm/js/JSWebAssemblyTable.h:
3005         * wasm/js/WasmToJS.cpp:
3006         (JSC::Wasm::materializeImportJSCell):
3007         (JSC::Wasm::handleBadI64Use):
3008         (JSC::Wasm::wasmToJS):
3009         * wasm/js/WebAssemblyFunctionBase.h:
3010         * wasm/js/WebAssemblyModuleRecord.cpp:
3011         (JSC::WebAssemblyModuleRecord::link):
3012         (JSC::WebAssemblyModuleRecord::evaluate):
3013         * wasm/js/WebAssemblyModuleRecord.h:
3014         * wasm/js/WebAssemblyToJSCallee.h:
3015         * wasm/js/WebAssemblyWrapperFunction.h:
3016
3017 2019-02-26  Mark Lam  <mark.lam@apple.com>
3018
3019         wasmToJS() should purify incoming NaNs.
3020         https://bugs.webkit.org/show_bug.cgi?id=194807
3021         <rdar://problem/48189132>
3022
3023         Reviewed by Saam Barati.
3024
3025         * runtime/JSCJSValue.h:
3026         (JSC::jsNumber):
3027         * runtime/TypedArrayAdaptors.h:
3028         (JSC::IntegralTypedArrayAdaptor::toJSValue):
3029         * wasm/js/WasmToJS.cpp:
3030         (JSC::Wasm::wasmToJS):
3031
3032 2019-02-26  Dominik Infuehr  <dinfuehr@igalia.com>
3033
3034         Fix warnings on ARM and MIPS
3035         https://bugs.webkit.org/show_bug.cgi?id=195049
3036
3037         Reviewed by Mark Lam.
3038
3039         Fix all warnings on ARM and MIPS.
3040
3041         * assembler/MacroAssemblerPrinter.cpp:
3042         (JSC::Printer::printMemory):
3043         * assembler/testmasm.cpp:
3044         (JSC::testProbeModifiesStackValues):
3045         * bytecode/InByIdStatus.cpp:
3046         (JSC::InByIdStatus::computeFor):
3047         * runtime/CachedTypes.cpp:
3048         (JSC::VariableLengthObject::buffer const):
3049         * runtime/JSBigInt.h:
3050         * tools/JSDollarVM.cpp:
3051         (JSC::codeBlockFromArg):
3052
3053 2019-02-26  Mark Lam  <mark.lam@apple.com>
3054
3055         Misc cleanup in StructureIDTable after r242096.
3056         https://bugs.webkit.org/show_bug.cgi?id=195063
3057
3058         Reviewed by Saam Barati.
3059
3060         * runtime/StructureIDTable.cpp:
3061         (JSC::StructureIDTable::allocateID):
3062         - RELEASE_ASSERT that the StructureID allocation will succeed.
3063
3064         * runtime/StructureIDTable.h:
3065         (JSC::StructureIDTable::decode):
3066         (JSC::StructureIDTable::encode):
3067         - Add back a comment that Yusuke requested but was lost when the patch was rolled
3068           out and relanded.
3069         - Applied bitwise_casts that Saam requested.
3070
3071 2019-02-26  Mark Lam  <mark.lam@apple.com>
3072
3073         Gardening: 32-bit build fix after r242096.
3074         https://bugs.webkit.org/show_bug.cgi?id=194989
3075
3076         Not reviewed.
3077
3078         * jit/AssemblyHelpers.cpp:
3079         (JSC::AssemblyHelpers::emitLoadStructure):
3080
3081 2019-02-26  Mark Lam  <mark.lam@apple.com>
3082
3083         Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
3084         https://bugs.webkit.org/show_bug.cgi?id=195039
3085
3086         Reviewed by Saam Barati.
3087
3088         1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
3089         2. Replace PoisonedClassInfoPtr with ClassInfo*.
3090         3. Replace PoisonedMasmPtr with const void*.
3091         4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.
3092
3093         * API/JSCallbackObject.h:
3094         * API/JSObjectRef.cpp:
3095         (classInfoPrivate):
3096         * assembler/MacroAssemblerCodeRef.h:
3097         (JSC::FunctionPtr::FunctionPtr):
3098         (JSC::FunctionPtr::executableAddress const):
3099         (JSC::FunctionPtr::retaggedExecutableAddress const):
3100         (JSC::ReturnAddressPtr::ReturnAddressPtr):
3101         (JSC::ReturnAddressPtr::value const):
3102         (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
3103         (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
3104         (JSC::MacroAssemblerCodePtr:: const):
3105         (JSC::MacroAssemblerCodePtr::operator! const):
3106         (JSC::MacroAssemblerCodePtr::operator== const):
3107         (JSC::MacroAssemblerCodePtr::hash const):
3108         (JSC::MacroAssemblerCodePtr::emptyValue):
3109         (JSC::MacroAssemblerCodePtr::deletedValue):
3110         (JSC::FunctionPtr<tag>::FunctionPtr):
3111         (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
3112         * b3/B3LowerMacros.cpp:
3113         * b3/testb3.cpp:
3114         (JSC::B3::testInterpreter):
3115         * dfg/DFGOSRExitCompilerCommon.h:
3116         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
3117         * dfg/DFGSpeculativeJIT.cpp:
3118         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
3119         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
3120         (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
3121         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
3122         (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
3123         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3124         * dfg/DFGSpeculativeJIT.h:
3125         * ftl/FTLLowerDFGToB3.cpp:
3126         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
3127         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
3128         * jit/AssemblyHelpers.h:
3129         (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
3130         * jit/ThunkGenerators.cpp:
3131         (JSC::virtualThunkFor):
3132         (JSC::boundThisNoArgsFunctionCallGenerator):
3133         * runtime/JSCPoison.h:
3134         * runtime/JSDestructibleObject.h:
3135         (JSC::JSDestructibleObject::classInfo const):
3136         * runtime/JSSegmentedVariableObject.h:
3137         (JSC::JSSegmentedVariableObject::classInfo const):
3138         * runtime/Structure.h:
3139         * runtime/VM.h:
3140         * wasm/WasmB3IRGenerator.cpp:
3141         (JSC::Wasm::B3IRGenerator::addCall):
3142         (JSC::Wasm::B3IRGenerator::addCallIndirect):
3143         * wasm/WasmBinding.cpp:
3144         (JSC::Wasm::wasmToWasm):
3145
3146 2019-02-26  Mark Lam  <mark.lam@apple.com>
3147
3148         [Re-landing] Add some randomness into the StructureID.
3149         https://bugs.webkit.org/show_bug.cgi?id=194989
3150         <rdar://problem/47975563>
3151
3152         Reviewed by Yusuke Suzuki.
3153
3154         1. On 64-bit, the StructureID will now be encoded as:
3155
3156             ----------------------------------------------------------------
3157             | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
3158             ----------------------------------------------------------------
3159
3160            The entropy bits are chosen at random and assigned when a StructureID is
3161            allocated.
3162
3163         2. Instead of Structure pointers, the StructureIDTable will now contain
3164            encodedStructureBits, which is encoded as such:
3165
3166             ----------------------------------------------------------------
3167             | 7 entropy bits |                   57 structure pointer bits |
3168             ----------------------------------------------------------------
3169
3170            The entropy bits here are the same 7 bits used in the encoding of the
3171            StructureID for this structure entry in the StructureIDTable.
3172
3173         3. Retrieval of the structure pointer given a StructureID is now computed as
3174            follows:
3175
3176                 index = structureID >> 7; // with arithmetic shift.
3177                 encodedStructureBits = structureIDTable[index];
3178                 structure = encodedStructureBits ^ (structureID << 57);
3179
3180             We use an arithmetic shift for the right shift because that will preserve
3181             the nuke bit in the high bit of the index if the StructureID was not
3182             decontaminated before use as expected.
3183
3184         4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
3185
3186         5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
3187            instead of always being the same as m_capacity.
3188
3189         6. Change StructureIDTable::s_unusedID's value to 0.
3190
3191            Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
3192            StructureID on 64-bit.  Also, there was never any code that initializes unused
3193            IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
3194            is the ID we'll get when the freelist is empty, prompting a resize of the
3195            structureIDTable.
3196
3197         This patch appears to be perf neutral on JetStream 2 run via the cli on a
3198         11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
3199
3200         * ftl/FTLLowerDFGToB3.cpp:
3201         (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
3202         * heap/SlotVisitor.cpp:
3203         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3204         * jit/AssemblyHelpers.cpp:
3205         (JSC::AssemblyHelpers::emitLoadStructure):
3206         * jit/AssemblyHelpers.h:
3207         * jit/SpecializedThunkJIT.h:
3208         (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
3209         * llint/LowLevelInterpreter.asm:
3210         * llint/LowLevelInterpreter64.asm:
3211         * runtime/StructureIDTable.cpp:
3212         (JSC::StructureIDTable::StructureIDTable):
3213         (JSC::StructureIDTable::makeFreeListFromRange):
3214         (JSC::StructureIDTable::resize):
3215         (JSC::StructureIDTable::allocateID):
3216         (JSC::StructureIDTable::deallocateID):
3217         * runtime/StructureIDTable.h:
3218         (JSC::StructureIDTable::decode):
3219         (JSC::StructureIDTable::encode):
3220         (JSC::StructureIDTable::get):
3221         (JSC::StructureIDTable::isValid):
3222
3223 2019-02-26  Ryan Haddad  <ryanhaddad@apple.com>
3224
3225         Unreviewed, rolling out r242071.
3226
3227         Breaks internal builds.
3228
3229         Reverted changeset:
3230
3231         "Add some randomness into the StructureID."
3232         https://bugs.webkit.org/show_bug.cgi?id=194989
3233         https://trac.webkit.org/changeset/242071
3234
3235 2019-02-26  Guillaume Emont  <guijemont@igalia.com>
3236
3237         [JSC] Fix compilation on 32-bit platforms after r242071
3238         https://bugs.webkit.org/show_bug.cgi?id=195042
3239
3240         Reviewed by Carlos Garcia Campos.
3241
3242         * jit/AssemblyHelpers.cpp:
3243         (JSC::AssemblyHelpers::emitLoadStructure):
3244
3245 2019-02-26  Guillaume Emont  <guijemont@igalia.com>
3246
3247         [JSC] Repeat string created from Array.prototype.join() take too much memory
3248         https://bugs.webkit.org/show_bug.cgi?id=193912
3249
3250         Reviewed by Saam Barati.
3251
3252         Added a fast case in Array.prototype.join when the array is
3253         uninitialized.
3254
3255         * runtime/ArrayPrototype.cpp:
3256         (JSC::canUseFastJoin):
3257         (JSC::fastJoin):
3258         * runtime/JSStringInlines.h:
3259         (JSC::repeatCharacter): moved from StringPrototype.cpp
3260         * runtime/StringPrototype.cpp:
3261
3262 2019-02-25  Mark Lam  <mark.lam@apple.com>
3263
3264         Add some randomness into the StructureID.
3265         https://bugs.webkit.org/show_bug.cgi?id=194989
3266         <rdar://problem/47975563>
3267
3268         Reviewed by Yusuke Suzuki.
3269
3270         1. On 64-bit, the StructureID will now be encoded as:
3271
3272             ----------------------------------------------------------------
3273             | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
3274             ----------------------------------------------------------------
3275
3276            The entropy bits are chosen at random and assigned when a StructureID is
3277            allocated.
3278
3279         2. Instead of Structure pointers, the StructureIDTable will now contain
3280            encodedStructureBits, which is encoded as such:
3281
3282             ----------------------------------------------------------------
3283             | 7 entropy bits |                   57 structure pointer bits |
3284             ----------------------------------------------------------------
3285
3286            The entropy bits here are the same 7 bits used in the encoding of the
3287            StructureID for this structure entry in the StructureIDTable.
3288
3289         3. Retrieval of the structure pointer given a StructureID is now computed as
3290            follows:
3291
3292                 index = structureID >> 7; // with arithmetic shift.
3293                 encodedStructureBits = structureIDTable[index];
3294                 structure = encodedStructureBits ^ (structureID << 57);
3295
3296             We use an arithmetic shift for the right shift because that will preserve
3297             the nuke bit in the high bit of the index if the StructureID was not
3298             decontaminated before use as expected.
3299
3300         4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
3301
3302         5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
3303            instead of always being the same as m_capacity.
3304
3305         6. Change StructureIDTable::s_unusedID's value to 0.
3306
3307            Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
3308            StructureID on 64-bit.  Also, there was never any code that initializes unused
3309            IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
3310            is the ID we'll get when the freelist is empty, prompting a resize of the
3311            structureIDTable.
3312
3313         This patch appears to be perf neutral on JetStream 2 run via the cli on a
3314         11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
3315
3316         * ftl/FTLLowerDFGToB3.cpp:
3317         (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
3318         * heap/SlotVisitor.cpp:
3319         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3320         * jit/AssemblyHelpers.cpp:
3321         (JSC::AssemblyHelpers::emitLoadStructure):
3322         * jit/AssemblyHelpers.h:
3323         * jit/Spec