Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-07T01:30:57Z

Rrastog3: /* Testing */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

==='''Final Project (Subsequent Steps)'''===

===Step 1===

* To enable the asynchronous compilation, we had to integrate event loop support and bind the runnable dispatching in the servo runtime. For this, we needed to pass NetworkingTaskSource object around new_rt_and_cx and new_rt_and_cx_with_parent functions in order to add the task in the job queue for execution.

[[File:SS1_1.png]]

* Implemented an extern "C" function, dispatch_to_event_loop in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper. Additionally, called the InitDispatchToEventLoop funtion in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument in new-rt_and_cx_with_parent passing the new function.

[[File:SS1_2.png]]

* Added rust JS::Runnable wrapper in script_runtime.rs that stores a pointer to the object and has a run method that calls the added C function, DispatchableRun, passing the stored pointer.

[[File:SS1_3.png]]

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

[[File:add_stream_consumer_to_response.png]]

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

[[File:add_stream_end_to_finish.png]]

===Step 3===

We added a stream_chunk method in the response class which invokes the consume_chunk() method defined for the StreamConsumer object. The consume_chunk() method Asynchronously compiles the WebAssembly module and returns a boolean value based on it's success.

[[File:stream_chunk.png]]

=='''Testing'''==

The changes we have made allow for asynchronous compilation of Web Assembly modules. After the changes we are able to load a website which makes use of WebAssembly promises. Here is the link to our [https://www.youtube.com/watch?v=SlEArNp288M&feature=youtube demo].

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:52:14Z

Rrastog3: /* Step 3 */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

[[File:add_stream_consumer_to_response.png]]

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

[[File:add_stream_end_to_finish.png]]

===Step 3===

We added a stream_chunk method in the response class which invokes the consume_chunk() method defined for the StreamConsumer object. The consume_chunk() method Asynchronously compiles the WebAssembly module and returns a boolean value based on it's success.

[[File:stream_chunk.png]]

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:50:50Z

Rrastog3: /* Implementation */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

[[File:add_stream_consumer_to_response.png]]

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

[[File:add_stream_end_to_finish.png]]

===Step 3===

We added a stream_chunk method in the response class which invokes the consume_chunk() method defined for the StreamConsumer object. This method Asynchronously compiles the WebAssembly module and returns a boolean value based on it's success.

[[File:stream_chunk.png]]

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

File:Stream chunk.png

2019-12-06T17:49:42Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:49:15Z

Rrastog3: /* Step 3 */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

[[File:add_stream_consumer_to_response.png]]

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

[[File:add_stream_end_to_finish.png]]

===Step 3===

We added a stream_chunk method in the response class which invokes the consume_chunk() method defined for the StreamConsumer object. This method Asynchronously compiles the WebAssembly module and returns a boolean value based on it's success.

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:35:28Z

Rrastog3: /* Implementation */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

[[File:add_stream_consumer_to_response.png]]

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

[[File:add_stream_end_to_finish.png]]

===Step 3===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

File:Add stream end to finish.png

2019-12-06T17:32:53Z

Rrastog3:

File:Add stream consumer to response.png

2019-12-06T17:32:24Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:31:58Z

Rrastog3: /* Step 2 */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

We added a Stream Consumer object defined in the initial steps to the Response structure.

In the Repsonse::finish() method we called the stream_end() function using the Stream Consumer object we recently added.

===Step 3===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:21:21Z

Rrastog3: /* Final Project (Subsequent Steps) */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

===Step 2===

===Step 3===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:19:04Z

Rrastog3: /* Scope */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:17:33Z

Rrastog3: /* References */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/ 
7. https://webassembly.org/ 
8. https://developer.mozilla.org/en-US/docs/WebAssembly

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:16:44Z

Rrastog3: /* Introduction */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

===Web Assembly===

[https://webassembly.org/ WebAssembly] is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:13:21Z

Rrastog3: /* Pull Request */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

===OSS Project (Initial Steps)===

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

===Final Project (Subsequent Steps)===

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:12:57Z

Rrastog3: /* Implementation */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===OSS Project (Initial Steps)===

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

===Final Project (Subsequent Steps)===

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

OSS Project (Initial Steps):

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

Final Project (Subsequent Steps):

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:11:41Z

Rrastog3: /* Pull Request */

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

OSS Project (Initial Steps):

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

Final Project (Subsequent Steps):

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-12-06T17:11:19Z

Rrastog3:

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of the project is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind its design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Scope'''==

Major browsers support the WebAssembly standard which can be used to implement performance-sensitive sandboxed applications. Servo is a new, experimental browser that supports synchronously compiling and executing WebAssembly code, but does not yet support asynchronous compilation. This means that the entire WebAssembly program must be fetched before compilation can begin, which leads to longer time loading pages that run WebAssembly programs than in other web browsers. The goal of this work is to support compiling WebAssembly programs asynchronously so compilation can begin while the program is still being fetched from the network.

The scope of this milestone was to complete the initial steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here]. The subsequent steps mentioned [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project here] are to be done for the final project.

The steps for the OSS project are as follows:

* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev

* Create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Implement an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming web assembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Implement an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* Lastly, call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments, described in the specifications

[[File:Steps.png|center]]

The steps for the final project are as follows:

* Binding runnable dispatching:
* Pass network task source into new_rt_and_cx functions
* Create rust JS::Runnable wrapper that stores a pointer to the object and has a run method that calls the new C function passing the stored pointer
* Create an extern "C" function in script_runtime.rs that matches DispatchToEventLoopCallback that casts the closure argument to a boxed network task source, wraps the runnable pointer in the new struct, and uses the network task source to queue a task that calls the run method of the wrapper
* Call InitDispatchToEventLoop in new_rt_and_cx_with_parent passing the new function and the boxed network task source as the closure argument /blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L2475) in new-rt_and_cx_with_parent passing the new function

* Add a stream consumer wrapper field to Response, and call the streamEnd method in Response::finish
* Add a stream_chunk method to Response and call it from FetchContext::process_response_chunk; this should invoke the consumeChunk method of the stream consumer wrapper if it exists.

[[File:Untitled Diagram.png|center]]

=='''Design Pattern'''==
Design patterns are not applicable as our task involved just implementation of methods. However, the Implementation section below provides details of the steps as why it was implemented, the way it was implemented

=='''Implementation'''==
The following steps were followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project github page].

===Step 1===

We have implemented a Stream Consumer structure which has the methods for consumeChunk, streamEnd, streamError, and noteResponseURLs based on the Stream Consumer class implemented in the Mozilla Spider Monkey module.

[[File:IS1-1.png]]

The note_response_urls function takes optional arguments as input, if nothing is passed it calls the underlying JS function with null ptr in place of the URLs.

[[File:IS1-2.png]]

===Step 2===

We implemented the consume stream function which checks if a response extracted from the source is valid and returns an appropriate boolean value. The function checks if the response has a valid mime type, is CORS- origin type and has an ok status. if the source cannot be extracted we throw a dom exception and return false.

[[File:IS2-1.png]]

This step checks if the response type is of "default", "cors" or "basic" type. This step checks the status code of the repsonse. It throws an error if the response is not OK ie. the status is not between 200 and 299.

[[File:IS2-2.png]]

These steps check if the response is locked. If the response is locked, it is not accessible and it throws a type error. If the response's body is already consumed, there is no need to process the response again. The function raises a corresponding type error.

[[File:IS2-3-1.png]]

===Step 3===

The implementation of the ReportStreamErrorCallback function to retrieve and report errors during stream compilation, CompileError, or TypeError in case of invalid Mime type and unprocessable stream.

[[File:IS3.png]]

===Step 4===

The implementation of InitStreamConsumerCallback in new_rt_and_cx_with_parent function. We call the Consume Stream callback added in step 2 and the Report Stream Error Callback added in Step 3 in new runtime environment.

[[File:IS4.png]]

=='''Testing'''==

The code added in the initial steps (scope) is not expected to have any change in behavior on its own. We loaded https://wasm.bootcss.com/demo/Tanks/ to verify that there is no change in behavior due to our changes.

In addition, we have tested our implementation against the servo-provided automated test suite using `./mach test-wpt tests/wpt/web-platform-tests/wasm/webapi` command.
The following image is the output of the said command:

[[File:Serv_tests.png]]

Following are the steps to compile the implementation to check for any broken code:

# Install the pre-requisites required for servo as mentioned [https://github.com/servo/servo/blob/master/README.md here]
# Run the following commands

<code>
cd
</code>

<code>
git clone https://github.com/Akash-Pateria/servo
</code>

<code>
cd servo
</code>

<code>
git checkout -b origin/async-wasm-compilation-initial
</code>

<code>
./mach fmt
</code>

<code>
./mach test-tidy
</code>

<code>
./mach build -d
</code>

You will see that the servo build is successful and no errors are reported.

=='''Pull Request'''==

OSS Project (Initial Steps):

[https://github.com/servo/servo/pull/24563 Pull Request 1] [https://github.com/servo/servo/pull/24653 Pull Request 2]

Final Project (Subsequent Steps):

[https://github.com/servo/servo/pull/24757 Pull Request 1] [https://github.com/servo/servo/pull/24977 Pull Request 2]

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-11T00:38:41Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-10T22:46:29Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-10T22:44:16Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-07T03:40:57Z

Rrastog3:

File:IS2-3-1.png

2019-11-07T03:40:41Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-07T03:39:20Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-07T03:36:12Z

Rrastog3:

File:IS-3.1.png

2019-11-07T03:35:35Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-11-07T03:34:43Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T20:14:51Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T20:14:16Z

Rrastog3:

File:ReportErrorCallback.png

2019-10-28T19:55:57Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:55:37Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:48:47Z

Rrastog3:

File:StreamConsumerFunctions.png

2019-10-28T19:47:53Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:40:58Z

Rrastog3: /* Implementation */

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:38:44Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:13:05Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T19:10:25Z

Rrastog3:

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:46:30Z

Rrastog3:

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Scope'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Testing'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:46:08Z

Rrastog3:

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Testing'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:42:30Z

Rrastog3:

Servo is a prototype web browser engine written in the [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust] language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:41:09Z

Rrastog3:

Servo is a prototype web browser engine written in the RUST language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==

===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:36:12Z

Rrastog3:

Servo is a prototype web browser engine written in the RUST language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==
## Servo
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/book 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:35:08Z

Rrastog3:

Servo is a prototype web browser engine written in the [RUST](http://en.wikipedia.org/wiki/JavaScript) language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==
## Servo
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

[https://doc.rust-lang.org/book/index.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2015/Mozilla Refactor GLES2

2019-10-28T18:33:14Z

Rrastog3:

'''' Refactor GLES2 Student Project with SERVO & RUST ''''

Servo is a prototype web browser engine written in the RUST language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==
===Servo===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

===Rust===
[https://doc.rust-lang.org/book/title-page.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* The next requirement was to build the Rust-layers independently of Servo. For this, we
* Next, we had to over-ride cargo to use our local copy of Rust-layers, so we had to add a cargo override to it. For this, we created a <code>.cargo</code> folder in our home directory(same place that servo and Rust-layers reside), and added a <code>config</code> file to that folder. The content of that config file is a path to our local Rust-layers.
paths = [path/to/rust_layers]
* Next, we had to add a new command line argument in Servo, which would allow selecting the graphics background (GL or ES2). For this, we made the following changes:
- We added a command line option which lets the user enter the option <code>-E</code> or <code>--es2</code> if the user wants to set ES2 as the graphic back end option. GL is set by default, hence if the user doesn't give any argument, Gl is selected as the graphic back end option. Example is as below
./mach run [url] -E
* Next, we had to add a flag in Rust-layers. This change was made in the file [https://github.com/prashantgupta24/rust-layers/blob/master/src/rendergl.rs Rust/src/rendergl.rs] in the <code>RenderContext::new</code> function. For this, we did the following change:
- We defined an enum <code>GraphicOption</code> which defined two options <code>GL</code> and <code>ES2</code> and then based on the boolean value from the servo <code>opts.rs</code>, we set a variable with the respective enum value <code>GL</code> or <code>ES2</code>.
* Finally, we had to use the new command line option to pass the selected graphics back-end option to the Rust-layers context which we created in the previous step. For this we made changes to the [https://github.com/prashantgupta24/servo/blob/master/components/compositing/compositor.rs compositor.rs] in Compositing folder which is how Servo interacts with the Rust layers. The command line option is passed through the <code>initialize_compositing</code> function.

=='''Design Pattern'''==
We attempted to follow good OO practices by implementing the [https://en.wikipedia.org/wiki/Strategy_pattern Strategy design pattern] using Enum.

=='''Conclusion'''==
After making our changes , the user can now dynamically pass in the option of GL or ES2 through the graphic command line option, and this option is passed on through the compositor to the rust layers during initialization. A video demonstration for the code changes is available [https://drive.google.com/file/d/0B9TVPg3YRoHqQUlvQXZkUUJPRzA/view?usp=sharing here]

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Refactor-GLES2-student-project 
5. http://doc.crates.io/guide.html#overriding-dependencies 
6. http://rustbyexample.com/ 
7. http://javarevisited.blogspot.com/2014/11/strategy-design-pattern-in-java-using-Enum-Example.html

CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation

2019-10-28T18:31:36Z

Rrastog3: Created page with " Servo is a prototype web browser engine written in the [RUST](http://en.wikipedia.org/wiki/JavaScript) language.Servo uses a variety of back-end implementations for drawing grap..."

Servo is a prototype web browser engine written in the [RUST](http://en.wikipedia.org/wiki/JavaScript) language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

=='''Introduction'''==
## Servo
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo]Servo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in [https://www.rust-lang.org/ Rust] language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

[http://doc.rust-lang.org/book/README.html Rust] is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

=='''Project Description'''==
* The project requirement initially stated that we build and Compile servo. Following are the steps for this:
Servo is built with [https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html Cargo], the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.

git clone https://github.com/servo/servo
cd servo
./mach build --dev
./mach run tests/html/about-mozilla.html

* Next we had to create a rust JS::StreamConsumer wrapper that stores a pointer to the object and has methods for consumeChunk, streamEnd, streamError, and noteResponseURLs.
* Then we had to create an extern "C" function in script_runtime.rs that matches ConsumeStreamCallback that initiates the streaming webassembly compilation then creates a wrapper for the stream consumer and stores it in the Response object
* Similarly we had to create an extern "C" function in script_runtime.rs that matches ReportStreamErrorCallback and reports an error with the error! macro
* The final step was to call InitStreamConsumerCallback in new_rt_and_cx with the two new functions as arguments

=='''Design Pattern'''==

=='''Conclusion'''==

=='''References'''==
1. https://doc.rust-lang.org/stable/book/ 
2. https://en.wikipedia.org/wiki/Rust_(programming_language) 
3. https://en.wikipedia.org/wiki/Servo_(layout_engine) 
4. https://github.com/servo/servo/wiki/Asynchronous-WebAssembly-compilation-project 
6. http://rustbyexample.com/

CSC/ECE 517 Fall 2019

2019-10-28T18:25:46Z

Rrastog3:

* [[CSC/ECE 517 Fall 2019 - Project E1947. Refactor quiz_questionnaire_controller.rb]]
* [[CSC/ECE 517 Fall 2019 - Project E1965. Review report should link to the usual view for reviews]]
* [[CSC/ECE 517 Fall 2019 - E1972. OSS project J. Skellington: Accessing Assignment Rubrics]]
* [[CSC/ECE 517 Fall 2019 - E1961. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2019 - E1971. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2019 - E1953. Tagging report for student]]
* [[CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student_task.rb]]
* [[CSC/ECE 517 Fall 2019 - E1954. Auto-generate submission directory names based on assignment names]]
* [[CSC/ECE 517 Fall 2019 - E1958. Two issues related to assignment management]]
* [[CSC/ECE 517 Fall 2019 - E1948. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2019 - E1959. Intelligent copying of assignments without topics]]
* [[CSC/ECE 517 Fall 2019 - E1968. Fixes for adding members to teams]]
* [[CSC/ECE 517 Fall 2019 - E1969. Fixes for reviews not being available]]
* [[CSC/ECE 517 Fall 2019 - E1951. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2019 - E1957. Time travel Not Allowed..!!! Restrict TAs’ ability to change their own grade + limit file-size upload]]
* [[CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role]]
* [[CSC/ECE 517 Fall 2019 - E1941. Issues related to topic deadlines]]
* [[CSC/ECE 517 Fall 2019 - E1966. Tabbed_reviews partial file refactor for displaying the alternate view of reviews]]
* [[CSC/ECE 517 Fall 2019 - E1962. Email notification upon account creation]]
* [[CSC/ECE 517 Fall 2019 - E1967. Fix glitches in author feedback]]
* [[CSC/ECE 517 Fall 2019 - E1960. Create new late policy successfully and fixing "Back" link]]
* [[CSC/ECE 517 Fall 2019 - E1939. OSS Project Juniper: Bookmark enhancements]]
* [[CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation]]