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