…jects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called

<https://webkit.org/b/235278>
<rdar://problem/87653812>

Unreviewed follow-up fix from Bug 235281, Comment #5.

* src/libANGLE/renderer/metal/DisplayMtl.mm:
(rx::DisplayMtl::getMetalDeviceMatchingAttribute):
- Remove unneeded calls to .get().


Canonical link: https://commits.webkit.org/246111@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    Follow-up: REGRESSION (r286603): Leak of three NSMutableDictionary objects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called
    <https://webkit.org/b/235278>
    <rdar://problem/87653812>

    Unreviewed follow-up fix from Bug 235281, Comment #5.

    * src/libANGLE/renderer/metal/DisplayMtl.mm:
    (rx::DisplayMtl::getMetalDeviceMatchingAttribute):
    - Remove unneeded calls to .get().

    Canonical link: https://commits.webkit.org/246111@main
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/245886.26@safari-613-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@288508 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    Follow-up: REGRESSION (r286603): Leak of three NSMutableDictionary objects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called
    <https://webkit.org/b/235278>
    <rdar://problem/87653812>

    Unreviewed follow-up fix from Bug 235281, Comment #5.

    * src/libANGLE/renderer/metal/DisplayMtl.mm:
    (rx::DisplayMtl::getMetalDeviceMatchingAttribute):
    - Remove unneeded calls to .get().

    Canonical link: https://commits.webkit.org/246111@main
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/245886.26@safari-613-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@288508 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=251063
rdar://104585575

Reviewed by Mark Lam and Justin Michaud.

This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace.
The example is as follows.

    frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt]
    frame WebKit#1: 0x000000010ec44204 0x10eccc5dc
    frame WebKit#2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined)
    frame WebKit#3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40)
    frame WebKit#4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40)
    frame WebKit#5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3)
    frame WebKit#6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0)
    frame WebKit#7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0)
    frame WebKit#8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#10: 0x000000010ec3c728
    frame WebKit#11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt]
    frame WebKit#12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt]
    frame WebKit#13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt]
    frame WebKit#14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt]
    frame WebKit#15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt]
    frame WebKit#16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt]
    ...

* Source/JavaScriptCore/interpreter/CallFrame.cpp:
(JSC::CallFrame::dump const):

Canonical link: https://commits.webkit.org/259262@main

https://bugs.webkit.org/show_bug.cgi?id=273715
rdar://127515199

Unreviewed test gardening.

* LayoutTests/platform/mac-site-isolation/TestExpectations:

Canonical link: https://commits.webkit.org/278703@main

…ter follows to the same value

https://bugs.webkit.org/show_bug.cgi?id=279570
rdar://135851156

Reviewed by Keith Miller.

Let's consider the following FTL graph.

    BB#0
    @0 = NewObject()
    Jump WebKit#1

    BB#1
    PutByOffset(@0, 0, @x)
    Jump WebKit#2

    BB#2
    ...
    @z = ...
    @1 = GetByOffset(@x, 0)
    Branch(@1, WebKit#3, WebKit#4)

    BB#3
    PutByOffset(@0, 0, @z)
    Jump WebKit#5

    BB#4
    PutByOffset(@0, 0, @z)
    Jump WebKit#5

    BB#5
    Jump WebKit#2

Now, we would like to eliminate @0 object allocation. And we are
computing SSA for pointers of fields of the that object which gets
eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def
and GetByOffset becomes Use. And the same field will get the same SSA
variable. So we first puts Defs and compute Phis based on that.

In ObjectAllocationSinking phase, we had a fast path when the both SSA
variable is following to the same value. Let's see BB#5. Because BB#3
and BB#4 defines Defs, dominance frontier BB#5 will need to introduce
Phi. But interestingly, both SSA variable is following to the same @z.
As a result, we were not inserting Phi for this case.

But this is wrong. Inserted Phi is a Def, and based on that, we will
further introduce Phis with that. If we omit inserting Phi in BB#5,
we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And
BB#5's Phi's Def. As a result, in BB#2, we think this variable is
following to BB#1's Def. But that's wrong and BB#5's Phi exists.

This patch removes this fast path to fix the issue.

* JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added.
(Queue):
(Queue.prototype.enqueue):
(Queue.prototype.dequeue):
(i.queue.dequeue):
* Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:

Canonical link: https://commits.webkit.org/283558@main

    [JSC] ObjectAllocationSinking should not omit phi insertion when pointer follows to the same value
    https://bugs.webkit.org/show_bug.cgi?id=279570
    rdar://135851156

    Reviewed by Keith Miller.

    Let's consider the following FTL graph.

        BB#0
        @0 = NewObject()
        Jump #1

        BB#1
        PutByOffset(@0, 0, @x)
        Jump #2

        BB#2
        ...
        @z = ...
        @1 = GetByOffset(@x, 0)
        Branch(@1, #3, #4)

        BB#3
        PutByOffset(@0, 0, @z)
        Jump #5

        BB#4
        PutByOffset(@0, 0, @z)
        Jump #5

        BB#5
        Jump #2

    Now, we would like to eliminate @0 object allocation. And we are
    computing SSA for pointers of fields of the that object which gets
    eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def
    and GetByOffset becomes Use. And the same field will get the same SSA
    variable. So we first puts Defs and compute Phis based on that.

    In ObjectAllocationSinking phase, we had a fast path when the both SSA
    variable is following to the same value. Let's see BB#5. Because BB#3
    and BB#4 defines Defs, dominance frontier BB#5 will need to introduce
    Phi. But interestingly, both SSA variable is following to the same @z.
    As a result, we were not inserting Phi for this case.

    But this is wrong. Inserted Phi is a Def, and based on that, we will
    further introduce Phis with that. If we omit inserting Phi in BB#5,
    we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And
    BB#5's Phi's Def. As a result, in BB#2, we think this variable is
    following to BB#1's Def. But that's wrong and BB#5's Phi exists.

    This patch removes this fast path to fix the issue.

    * JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added.
    (Queue):
    (Queue.prototype.enqueue):
    (Queue.prototype.dequeue):
    (i.queue.dequeue):
    * Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:

    Canonical link: https://commits.webkit.org/283558@main

Canonical link: https://commits.webkit.org/280938.337@safari-7619-branch

Reviewed by NOBODY (OOPS!).

This was spotted by ASan, the real and imaginary AudioFloatArrays end-up using aligned_alloc() for
their storage, which expects a power-of-two size. Using fftSize / 2 + 1 makes the size
non-power-of-two, the full fftSize being power-of-two (we now have an ASSERT for this).

==1733723==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc75c438bca bp 0x7ffed612c860 sp 0x7ffed612c028 T0)
==1733723==The signal is caused by a WRITE memory access.
==1733723==Hint: address points to the zero page.
    #0 0x7fc75c438bca in __memset_avx2_unaligned_erms (/lib64/libc.so.6+0x16dbca) (BuildId: 77c77fee058b19c6f001cf2cb0371ce3b8341211)
    WebKit#1 0x2fc4ce in __asan_memset (/var/home/phil/WebKit/local-build-gtk/WebKitBuild/GTK/Release/bin/WebKitWebProcess+0x2fc4ce) (BuildId: e2b0aff0c8fcab48026d63cf711cd70d0aeceb79)
    WebKit#2 0x7fc77047599e in WebCore::FFTFrame::FFTFrame(unsigned int) UnifiedSource-3c72abbe-20.cpp
    WebKit#3 0x7fc76d41c08b in WebCore::PeriodicWave::createBandLimitedTables(float const*, float const*, unsigned int, WebCore::ShouldDisableNormalization) UnifiedSource-f8afad56-52.cpp
    WebKit#4 0x7fc76d41f371 in WebCore::PeriodicWave::generateBasicWaveform(WebCore::PeriodicWave::Type) UnifiedSource-f8afad56-52.cpp
    WebKit#5 0x7fc76d41e633 in WebCore::PeriodicWave::createSine(float) UnifiedSource-f8afad56-52.cpp
    WebKit#6 0x7fc76d3c2352 in WebCore::BaseAudioContext::periodicWave(WebCore::OscillatorType) UnifiedSource-f8afad56-49.cpp
    WebKit#7 0x7fc76d410dbf in WebCore::OscillatorNode::setTypeForBindings(WebCore::OscillatorType) UnifiedSource-f8afad56-52.cpp
    WebKit#8 0x7fc76d4102f4 in WebCore::OscillatorNode::create(WebCore::BaseAudioContext&, WebCore::OscillatorOptions const&) UnifiedSource-f8afad56-52.cpp
    WebKit#9 0x7fc76d3bc210 in WebCore::BaseAudioContext::createOscillator() UnifiedSource-f8afad56-49.cpp
    WebKit#10 0x7fc76acbc743 in WebCore::jsBaseAudioContextPrototypeFunction_createOscillator(JSC::JSGlobalObject*, JSC::CallFrame*) UnifiedSource-3a52ce78-11.cpp
    WebKit#11 0x7fc705c10037  (<unknown module>)

* Source/WebCore/platform/audio/gstreamer/FFTFrameGStreamer.cpp:
(WebCore::FFTFrame::FFTFrame):

https://bugs.webkit.org/show_bug.cgi?id=316798

Reviewed by NOBODY (OOPS!).

To improve traceability, this commit adds RELEASE_LOG statements
covering the following areas of Source/WebDriver:

- Browser startup and lifetime (for glib ports)
- HTTP request and response
- Driver->Browser Automation.json commands and replies.

The added log statements cover mainly data like the request path, body
size, response status, and duration. The actual body with payload like
field values or JS code to be executed is omitted. For deeper
inspection, the existing LOG() statements that inspect the actual
payload are kept.

We opted for RELEASE_LOG instead of LOG due to the WebDriver-related
channels being low-volume in comparison to hotter ones internal to the
browser. On top of that, it should be easier for reporters to provide
release logs, helping get more useful bug reports.

Example output:

Started WebSocket BiDi server with host local and port 60782
Started HTTP server with host local and port 60781
HTTP request POST /session (body=303 bytes)
Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s)
Connecting to RemoteInspector at 127.0.0.1:54821
Connected to RemoteInspector at 127.0.0.1:54821 after 1 attempt(s)
    SEND inspector WebKit#1: Automation.createBrowsingContext (52 bytes)
    RECV inspector WebKit#1: ok
HTTP response 200 in 196ms
HTTP request POST /session/fbc9c527-945d-4030-852e-50c5f1852557/url (body=43 bytes)
    SEND inspector WebKit#2: Automation.resolveBrowsingContext (149 bytes)
    RECV inspector WebKit#2: ok
    SEND inspector WebKit#3: Automation.waitForNavigationToComplete (207 bytes)
    RECV inspector WebKit#3: ok
    SEND inspector WebKit#4: Automation.isShowingJavaScriptDialog (135 bytes)
    RECV inspector WebKit#4: ok
    SEND inspector WebKit#5: Automation.navigateBrowsingContext (212 bytes)
    RECV inspector WebKit#5: ok
HTTP response 200 in 124ms

* Source/WebDriver/SessionHost.cpp:
(WebDriver::SessionHost::inspectorDisconnected):
(WebDriver::SessionHost::sendCommandToBackend):
(WebDriver::SessionHost::dispatchMessage):
* Source/WebDriver/WebDriverService.cpp:
(WebDriver::printUsageStatement):
(WebDriver::WebDriverService::run):
(WebDriver::WebDriverService::handleRequest):
* Source/WebDriver/glib/SessionHostGlib.cpp:
(WebDriver::SessionHost::launchBrowser):
(WebDriver::SessionHost::connectToBrowser):
(WebDriver::SessionHost::connectionDidClose):
(WebDriver::SessionHost::setTargetList):

https://bugs.webkit.org/show_bug.cgi?id=316798

Reviewed by BJ Burg.

To improve traceability, this commit adds RELEASE_LOG statements
covering the following areas of Source/WebDriver:

- Browser startup and lifetime (for glib ports)
- HTTP request and response
- Driver->Browser Automation.json commands and replies.

The added log statements cover mainly data like the request path, body
size, response status, and duration. The actual body with payload like
field values or JS code to be executed is omitted. For deeper
inspection, the existing LOG() statements that inspect the actual
payload are kept.

We opted for RELEASE_LOG instead of LOG due to the WebDriver-related
channels being low-volume in comparison to hotter ones internal to the
browser. On top of that, it should be easier for reporters to provide
release logs, helping get more useful bug reports.

Example output:

Started WebSocket BiDi server with host local and port 60782
Started HTTP server with host local and port 60781
HTTP request POST /session (body=303 bytes)
Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s)
Connecting to RemoteInspector at 127.0.0.1:54821
Connected to RemoteInspector at 127.0.0.1:54821 after 1 attempt(s)
    SEND inspector WebKit#1: Automation.createBrowsingContext (52 bytes)
    RECV inspector WebKit#1: ok
HTTP response 200 in 196ms
HTTP request POST /session/fbc9c527-945d-4030-852e-50c5f1852557/url (body=43 bytes)
    SEND inspector WebKit#2: Automation.resolveBrowsingContext (149 bytes)
    RECV inspector WebKit#2: ok
    SEND inspector WebKit#3: Automation.waitForNavigationToComplete (207 bytes)
    RECV inspector WebKit#3: ok
    SEND inspector WebKit#4: Automation.isShowingJavaScriptDialog (135 bytes)
    RECV inspector WebKit#4: ok
    SEND inspector WebKit#5: Automation.navigateBrowsingContext (212 bytes)
    RECV inspector WebKit#5: ok
HTTP response 200 in 124ms

* Source/WebDriver/SessionHost.cpp:
(WebDriver::SessionHost::inspectorDisconnected):
(WebDriver::SessionHost::sendCommandToBackend):
(WebDriver::SessionHost::dispatchMessage):
* Source/WebDriver/WebDriverService.cpp:
(WebDriver::printUsageStatement):
(WebDriver::WebDriverService::run):
(WebDriver::WebDriverService::handleRequest):
* Source/WebDriver/glib/SessionHostGlib.cpp:
(WebDriver::SessionHost::launchBrowser):
(WebDriver::SessionHost::connectToBrowser):
(WebDriver::SessionHost::connectionDidClose):
(WebDriver::SessionHost::setTargetList):

Canonical link: https://commits.webkit.org/316784@main