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