Wasm Tests Failed When Sandbox is 256GB

[Liu Yu]

Hi all,

When porting the code pointer sandbox, I set the sandbox size on loong64 to 256GB because some loongarch machines are configured with only 40-bit virtual address space for user space.

However, after the port, I found that some wasm tests would fail, such as

=== wasm-spec-tests/memory_copy ===                    
test/wasm-spec-tests/tests/memory_copy.js:74: RangeError: WebAssembly.Instance(): Out of memory: Cannot allocate Wasm memory for new instance
  return new WebAssembly.Instance(module(bytes), imports);
         ^
RangeError: WebAssembly.Instance(): Out of memory: Cannot allocate Wasm memory for new instance
    at instance (test/wasm-spec-tests/tests/memory_copy.js:74:10)
    at test/wasm-spec-tests/tests/memory_copy.js:12772:11
Command: out_dir/loong64.release/d8 --test test/wasm-spec-tests/tests/memory_copy.js --random-seed=967154330 --nohard-abort --testing-d8-test-runner
--- FAILED ---

I changed the sandbox size  to 256GB on arm64 linux, and tests will also go wrong. It seems that the error is caused by insufficient memory in the sandbox.

Tests like wasm-spec-tests/memory_copy and wasm-spec-tests/memory_init include many small wasm casts; Is the number of wasm instance also part of the test, or does it only need to be correct for each small instance? On real-world websites, will there be an error due to insufficient memory because the sandbox is too small?

[Andreas Haas]

Hi,

The test allocates 33 wasm memories, 10GB each. It can be that in such a situation garbage collection of wasm memories does not work perfectly, and eventually it cannot find memory anymore to allocate. The tests don't test if you are 

able to allocate a large number of wasm instances and wasm memories, this is just a side effect.On real-world websites there are typically not so many wasm memories, and they are used more and for longer so that the GC can keep up with it. 

Cheers, Andreas

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/e2051aee-c1ee-46a3-97a2-8442984cc384n%40googlegroups.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Clemens Backes]

If you look at the JS test file, it contains lots of these lines:

let $1 = instance(...);

assert...($1, ...);

let $2 = instance(...);

assert...($2, ...);

So the instances (and also the contained memory objects) never go out of scope.

These files are generated from the spec tests (written in wast format) by the reference interpreter. This translation is implemented in the js.ml file.

If you know OCaml you could upload a PR to either reset the instances when they are not needed any more ($1 = undefined), or to scope the instances.

If you don't know OCaml, you could also open an issue in the spec repository and see if someone is willing to fix this.

-Clemens

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAELSTve1VR7-51nj2DOF27UOGRB_6G5Dhp4dJhHU6UW8k-3Okw%40mail.gmail.com.

--

Clemens Backes

Software Engineer

clem...@google.com

[Liu Yu]

Thanks for reply !

This seems to have no side effects for real-world websites.

And I don't know OCaml, so I will  open an issue in v8.

[Clemens Backes]

On Thu, Oct 26, 2023 at 2:40 PM Liu Yu <li...@loongson.cn> wrote:

Thanks for reply !

This seems to have no side effects for real-world websites.

And I don't know OCaml, so I will  open an issue in v8.

This will need to be fixed in the spec repository, so please file an issue there: https://github.com/WebAssembly/spec/issues

 

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/8102bd81-d951-4f3c-a050-dcf690531b7bn%40googlegroups.com.

[Liu Yu]

Oh, that was my misunderstanding.

I will open an issue there.