Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSoC 2019 Webkit2 work #4

Open
wants to merge 44 commits into
base: haiku
Choose a base branch
from
Open

GSoC 2019 Webkit2 work #4

wants to merge 44 commits into from

Conversation

pulkomandy
Copy link
Member

Here is the final work submitted by Rajagopalan during GSoC 2019. Unfortunately, it is based on a very old version of WebKit and HaikuWebKit and not easy to rebase.

I think the best way to move on is to cherry pick what's needed from here, and redo the work to get WebKit2 up and running on top of a newer version of haikuwebkit.

pulkomandy and others added 30 commits January 28, 2021 22:05
Bulk import without cleanup. The goal is only to preserve the next
commits in the GSoC 2019 webkit2 branch.
Again, no cleanup is attempted. Just archiving the GSoC 2019 WebKit2
work in the next commits
This lets us use our native APIs to reserve address space without
allocating memory for it immediately. Gets HaikuLauncher down to about
30MB of RAM used to display Google homepage, instead of 40MB before on
32bit systems.

Untested yet on 64bit but it should free about 1GB there.
Replace our broken implementation by one done by waddlesplash based on
the curl one:
- Does not need to run two threads
- Does not crash
- Supports SSL

There is one limitation: we don't have a way to wait for a socket to be
either readable or writable. So get away with timeouts for now. I'll
revisit that after I figure out a way to add a WaitForReadableOrWritable
to BSocket and BSecureSocket (trying to not break the ABI while doing
so).
Thanks to the work done on updating to webkit2, we now have working
"forwarding headers" generation. This means the public headers for
WebCore are copied to a directory where WebKitLegacy and WebKit2 can
easily locate them. This allows to cleanup a lot of the include path
tricks we were playing to get things working before.
This completes the cleanup of the forwarding headers setup. I had missed
these the last time because I had not done a full clean build.
Add a static_assert to make sure pid_t fits there.
Add conversion functions but I think they will not be needed (C integer
promotion will do the magic)
For now have ignored the case of posting a message to main run loop.
So it isn't doing much yet.
Who wants to use fork/exec when we have much nicer native APIs?
We need a MIME signature so the roster can find it.
- Added a message handler to look out for incoming messages to runloop
- Created new aux support so we can attach all handlers to the main apps looper
- Added a message stashing feature so it stashes the messages and interprets them when the loop is ready to run
- used maps to store loopers and BApplications to forward message to appropriate loopers
- Created a message from ui process to network process that notifies the pid of webprocess
- Added NetworkSession so it doesnt crash
- Add minimal support for ANGLE as build is broken when disabling it
- Fix various minor things in Haiku specific files
- A bit more cleanup of include files and forwarding headers management
1)This makes few important changes in adding the view
2)Partial mouse events which is kept aside now as main focus is put on webpage rendering
1) Few callbacks for finished loading and forward and backward stop etc is now fully functional
2) status text is partially done
3)shared memory done with mapping part pending(i need to understand a little bit more)
Fix various include path, do not include ANGLE headers when not needed.
Some headers are added to the forwarding headers that probably shouldn't
need to be there (date time chooser stuff, and not sure about image and
image buffer). But it gets things working at least and it's more clean
than what we had before.
1) removed unwanted comments
2) removed unwanted methods
1) Loading, changing title and adding redirected url are added to minibrowser
2) Get data and run on main thread - fixes network process run on main thread problem
1) Put widgets in window thread
2) webkit events on main thread
1) Enabled 3D Rendering
2) Shareable Bitmap to get data and initialize a bitmap
3) Added few drawing mechanisms to webview
4) Backing store update
Use a NativeImagePtr so the constructor will automatically initialize
it.
We still need it for now and it's not that hard to keep it working.
Link it with OpenGL and disable coordinated graphics as we don't need
that for now.
1) Loading, changing title and adding redirected url are added to minibrowser
2) Get data and run on main thread - fixes network process run on main thread problem
1) Removed that painful wait between network and webprocess connection

2) Resizing a webpage ( very slow )
1) Cleanup all the unwanted debug messages

2) More predictable rendering

Next commit would focus on Indentation
1) Inconsistent use of spaces and tabs

I had to clean up this manually as i couldnt find a good extension
So i will clean even more files if i come across them
1) Moved handhskaing as a part of internal WebView API

2) Placed Invalidation right after backing store changes
i think this is the best place to invalidate- now paints without having to switch workspaces
pulkomandy pushed a commit that referenced this pull request Dec 19, 2021
…nstead of _relevant_

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

Patch by Alexey Shvayka <[email protected]> on 2021-12-10
Reviewed by Sam Weinig.

LayoutTests/imported/w3c:

Import WPT tests from web-platform-tests/wpt#32012.

* web-platform-tests/dom/events/Event-timestamp-cross-realm-getter-expected.txt: Added.
* web-platform-tests/dom/events/Event-timestamp-cross-realm-getter.html: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_back_cross_realm_method-expected.txt: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_back_cross_realm_method.html: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_forward_cross_realm_method-expected.txt: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_forward_cross_realm_method.html: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_go_cross_realm_method-expected.txt: Added.
* web-platform-tests/html/browsers/history/the-history-interface/history_go_cross_realm_method.html: Added.
* web-platform-tests/html/webappapis/scripting/reporterror-cross-realm-method-expected.txt: Added.
* web-platform-tests/html/webappapis/scripting/reporterror-cross-realm-method.html: Added.
* web-platform-tests/html/webappapis/structured-clone/structured-clone-cross-realm-method-expected.txt: Added.
* web-platform-tests/html/webappapis/structured-clone/structured-clone-cross-realm-method.html: Added.
* web-platform-tests/requestidlecallback/callback-timeRemaining-cross-realm-method-expected.txt: Added.
* web-platform-tests/requestidlecallback/callback-timeRemaining-cross-realm-method.html: Added.

Source/WebCore:

This patch replaces _current_ global object with _relevant_, as per recommendation
for spec authors [1], for select WebIDL operations / attributes that satisfy all
the following conditions:

  1) it's an instance member: static ones and constructors can't use _relevant_;
  2) it's on standards track (not deprecated / WebKit-only / internal);
  3) the change is directly observable: global object is used for something
     beyond lifecycle / event loop / parsing CSS etc;
  4) the change either aligns WebKit with both Blink and Gecko,
     or the spec explicitly requires _relevant_ realm / settings object.

Most of the remaining [CallWith=GlobalObject] instances are correctly used for
converting JS arguments to WebIDL values; the rest, along with _current_ Document
and ScriptExecutionContext, either match the spec or replacing them with _relevant_
global object is not directly observable (see condition #3).

This change is aimed at fixing web-exposed APIs rather than performing a global cleanup.

[1] https://html.spec.whatwg.org/multipage/webappapis.html#concept-current-everything

Tests: imported/w3c/web-platform-tests/dom/events/Event-timestamp-cross-realm-getter.html
       imported/w3c/web-platform-tests/html/browsers/history/the-history-interface/history_back_cross_realm_method.html
       imported/w3c/web-platform-tests/html/browsers/history/the-history-interface/history_forward_cross_realm_method.html
       imported/w3c/web-platform-tests/html/browsers/history/the-history-interface/history_go_cross_realm_method.html
       imported/w3c/web-platform-tests/html/webappapis/scripting/reporterror-cross-realm-method.html
       imported/w3c/web-platform-tests/html/webappapis/structured-clone/structured-clone-cross-realm-method.html
       imported/w3c/web-platform-tests/requestidlecallback/callback-timeRemaining-cross-realm-method.html

* Modules/indexeddb/IDBFactory.idl:
https://www.w3.org/TR/IndexedDB/#dom-idbfactory-open (step 2)
https://www.w3.org/TR/IndexedDB/#dom-idbfactory-deletedatabase (step 1)
https://www.w3.org/TR/IndexedDB/#dom-idbfactory-databases (step 1)

* Modules/paymentrequest/PaymentRequest.idl:
https://www.w3.org/TR/payment-request/#show-method (steps 2-4)
https://www.w3.org/TR/payment-request/#can-make-payment-algorithm (before step 1)

* bindings/scripts/CodeGeneratorJS.pm:
(GenerateCallWith):
* bindings/scripts/IDLAttributes.json:
* bindings/scripts/test/JS/JSTestObj.cpp:
* bindings/scripts/test/TestObj.idl:
* dom/Event.idl:
https://dom.spec.whatwg.org/#inner-event-creation-steps (step 3)

* dom/IdleDeadline.idl:
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method (step 1)

* page/History.idl:
https://html.spec.whatwg.org/multipage/history.html#dom-history-go (step 1)
https://html.spec.whatwg.org/multipage/history.html#dom-history-back (step 1)
https://html.spec.whatwg.org/multipage/history.html#dom-history-forward (step 1)

* page/DOMWindow.cpp:
(WebCore::DOMWindow::setTimeout):
(WebCore::DOMWindow::setInterval):
* page/DOMWindow.h:
* workers/WorkerGlobalScope.cpp:
(WebCore::WorkerGlobalScope::setTimeout):
(WebCore::WorkerGlobalScope::setInterval):
* workers/WorkerGlobalScope.h:
Although condition #4 isn't satisfied for setTimeout() / setInterval() because
_current_ global object is used only for logging, replacing it with _relevant_
nicely cleans up method signatures.

* page/WindowOrWorkerGlobalScope.cpp:
(WebCore::WindowOrWorkerGlobalScope::structuredClone):
* page/WindowOrWorkerGlobalScope.h:
* page/WindowOrWorkerGlobalScope.idl:
https://html.spec.whatwg.org/multipage/webappapis.html#report-the-exception
https://html.spec.whatwg.org/multipage/structured-data.html#structured-cloning (step 2)


Canonical link: https://commits.webkit.org/245123@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@286895 268f45cc-cd09-0410-ab3c-d52691b4dbfc
pulkomandy pushed a commit that referenced this pull request Mar 5, 2023
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 #1: 0x000000010ec44204 0x10eccc5dc
    frame #2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined)
    frame #3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40)
    frame #4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40)
    frame #5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3)
    frame #6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0)
    frame #7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0)
    frame #8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame #9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame #10: 0x000000010ec3c728
    frame #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 #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 #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 #14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt]
    frame #15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt]
    frame #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
pulkomandy pushed a commit that referenced this pull request Sep 28, 2024
…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 #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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants