Hi everyone,

I wanted to approach the group to understand the feasibility of creating a
root relative constant pool for WASM to support reuse of intermediate
constants generated during complex instruction sequences.

Right now, when a complex instruction sequence like shuffle or swizzle
operates and cannot find an architectural match for the requested
operation, it generates in flight code to build shuffle masks which are
passed to pshufb on x64 and tbl on a64. Due to the current nature of the
code generator / assembler, these can be regenerated multiple times even if
the input is constant (https://bugs.chromium.org/p/v8/issues/detail?id=11545
).

Two options exist for resolving this.

1) Generating a constant pool for the code to use at compile time and
loading the data from there.
2) Lifting sections of multi instruction code up to the graph for
optimization and reduction.

Each is a partial solution since both can benefit from the other.

What I'd like to enquire now is the first option -- the feasibility of
implementing an isolate root relative constant pool.

>From what I can see, this might be an easy and effective solution covering
address moves, security concerns, and alignment.

Since isolate() has a single coherent heap that is garbage collected and
moved (https://v8.dev/blog/embedded-builtins), one can allocate objects
relative to the root. If you use it with the ExternalReference operand
mechanism we've been using, it'll automatically generate all of the address
constants relative to the root register (
https://source.chromium.org/chromium/chromium/src/+/master:v8/src/codegen/x64/macro-assembler-x64.cc;l=124;bpv=1;bpt=1).
This should preclude any concerns about addresses moving when the heap
moves or gets reallocated. Likewise, isolate()->factory() provides
mechanisms for aligning the pointers on each allocation. As such, if an
external data structure such as a map or hash map is used to track the
constants at code generation time, then each constant can be allocated
individually on the isolate heap without respect to any other. If the heap
persists the entire duration of the executed code and is deallocated at the
end, then there are no memory management concerns. Lastly, there should be
no security concerns since the data allocated on the isolate heap will not
be executable by default.

Is this correct? If so, what's the appropriate process for submitting and
reviewing a design proposal?

Dan

-- 
-- 
v8-dev mailing list
v8-dev@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-dev/CAAg-m6qF47m8fP81GoeeM4YJBaBAC8%2BY_z%3DcmanviBBeQTsD_A%40mail.gmail.com.

Reply via email to