Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Fix table and memory import and improve memory storage #11

Closed
wants to merge 2 commits into from
Closed

Fix table and memory import and improve memory storage #11

wants to merge 2 commits into from

Conversation

appcypher
Copy link
Contributor

What does this PR do?

  • Fix issues related to table, memory, function and global import
  • Fix issues that prevent support for multiple tables
  • Add proper support for multiple memories
  • Optimize memories storage strategy

How should this be manually tested?

  • Run cargo test.

Background context

N/A

Areas needing improvement

All of these cause certain tests to fail.

  • ImportObject is currently not shareable between instances.
  • There is no way to know the names of imported tables/memories.
  • Using global values as offset into tables is currently not supported.

- `call_indirect.wast`

- `SKIP_SHARED_TABLE` [elem.wast]
Currently sharing tables between instances/modules does not work. Below are some of the reasons it is hard to achieve.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love seeing this analysis as part of the PR and spectests README.

It will make much easier to dig into a solution in the future and get input/solutions from other people.
Great 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@@ -9,15 +9,19 @@ pub struct UncheckedSlice<T> {

impl<T> UncheckedSlice<T> {
#[inline]
unsafe fn get_unchecked(&self, index: usize) -> &T {
pub fn get_unchecked(&self, index: usize) -> &T {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason on make the function "safe" rather than moving the safe responsibility on the caller?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I don't do that, the unsafe annotation propagates. That is, the function that calls it needs to be annotated as unsafe and the function that calls that and ....

pub struct BoundedSlice<T> {
data: UncheckedSlice<T>,
len: usize,
pub data: UncheckedSlice<T>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it really need to be public other than for debugging proposes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If so, it might be better to make it private and comment the public access on the print_instance_offsets.
Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just for debugging purpose only.

Copy link
Contributor Author

@appcypher appcypher Nov 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we don't really need print_instance_offsets function.

}

impl Instance {
pub const TABLES_OFFSET: usize = 0; // 0 on 64-bit | 0 on 32-bit
pub const MEMORIES_OFFSET: usize = size_of::<TablesSlice>(); // 8 on 64-bit | 4 on 32-bit
pub const GLOBALS_OFFSET: usize = Instance::MEMORIES_OFFSET + size_of::<MemoriesSlice>(); // 16 on 64-bit | 8 on 32-bit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I was using a dynamic calculation in module.rs based on the pointer size in the latests commits of wasmer.
But I think I like yours better 💯 (and actually it's similar on how SpiderMonkey handles it).

@appcypher appcypher closed this Nov 17, 2018
syrusakbary added a commit that referenced this pull request Aug 1, 2019
Each time `make capi` is run, there is a flaky error:

```
Running target/release/deps/runtime_c_api_tests-3df0f74fcea1252d

running 1 test
test test_c_api ... FAILED

failures:

---- test_c_api stdout ----
Running command: `cmake` arg: Some(".")
output:
status: 0
stdout:
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/syrusakbary/Development/wasmer/lib/runtime-c-api/tests

stderr:

Running command: `make` arg: Some("-Wdev -Werror=dev")
output:
status: 0
stdout:
[  7%] Built target test-tables
[ 15%] Built target test-module-exports
[ 23%] Built target test-module-imports
[ 30%] Built target test-globals
[ 38%] Built target test-imports
[ 46%] Built target test-module
[ 53%] Built target test-module-serialize
[ 61%] Built target test-memory
[ 69%] Built target test-validate
[ 76%] Built target test-import-function
[ 84%] Built target test-instantiate
[ 92%] Built target test-exports
[100%] Built target test-exported-memory

stderr:

Running command: `make` arg: Some("test")
output:
status: 2
stdout:
Running tests...
Test project /Users/syrusakbary/Development/wasmer/lib/runtime-c-api/tests
      Start  1: test-exported-memory
 1/13 Test  #1: test-exported-memory .............Child aborted***Exception:   0.00 sec
      Start  2: test-exports
 2/13 Test  #2: test-exports .....................   Passed    0.01 sec
      Start  3: test-globals
 3/13 Test  #3: test-globals .....................   Passed    0.00 sec
      Start  4: test-import-function
 4/13 Test  #4: test-import-function .............   Passed    0.01 sec
      Start  5: test-imports
 5/13 Test  #5: test-imports .....................   Passed    0.01 sec
      Start  6: test-instantiate
 6/13 Test  #6: test-instantiate .................   Passed    0.01 sec
      Start  7: test-memory
 7/13 Test  #7: test-memory ......................   Passed    0.00 sec
      Start  8: test-module
 8/13 Test  #8: test-module ......................   Passed    0.01 sec
      Start  9: test-module-exports
 9/13 Test  #9: test-module-exports ..............   Passed    0.01 sec
      Start 10: test-module-imports
10/13 Test #10: test-module-imports ..............   Passed    0.01 sec
      Start 11: test-module-serialize
11/13 Test #11: test-module-serialize ............   Passed    0.01 sec
      Start 12: test-tables
12/13 Test #12: test-tables ......................   Passed    0.00 sec
      Start 13: test-validate
13/13 Test #13: test-validate ....................   Passed    0.00 sec

92% tests passed, 1 tests failed out of 13

Total Test time (real) =   0.08 sec

The following tests FAILED:
	  1 - test-exported-memory (Child aborted)

stderr:
Errors while running CTest
make[1]: *** [test] Error 8

thread 'test_c_api' panicked at 'Command failed with exit status: ExitStatus(ExitStatus(512))', lib/runtime-c-api/tests/runtime_c_api_tests.rs:43:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```
MarkMcCaskey pushed a commit that referenced this pull request Apr 14, 2020
nlewycky pushed a commit that referenced this pull request Aug 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants