I'd like to try to clear up the understanding of memory handling a bit: There is indeed the option to put stuff into the Isolate, so that root-relative addressing can be used to access it. This makes sense when the amount of data is fixed and statically known (for example: a list of all builtins that exist). It's also true that there's a 1:1 relation between Isolates and Heaps, but that's the managed heap! If you use the Factory to allocate an object, then it lives on the managed heap. It'll (potentially) move around on GC, you need Handles to refer to it from C++ code, and you can't use root-relative addressing to get to it.
So if you want to store constants required by a specific compiled function (and not particularly likely to be shared by other functions), then their storage should be dynamic and have the same lifetime as the code that needs them. Putting them right inside the code is an easy way to achieve that (though with security downsides, as Clemens points out), and in fact that's what "constant pool" has historically meant in V8. Putting them elsewhere (non-executable) but "nearby" would be even better. I hope this helps at least a little bit, and that I'm not misunderstanding the whole idea (not familiar with SIMD). On Wed, Mar 17, 2021 at 5:16 PM Zhi An Ng <[email protected]> wrote: > We did a little exploration on this when trying to optimize shuffles, see > relevant design doc ( > https://docs.google.com/document/d/1uCYwyQYjgNAtaXDNgHusDGCV1m9YGhOWJx2eqzv2rdI/edit). > We ultimately decided against it because we found another way to improve > shuffle performance without adding a constant pool. > > +Brown, Andrew <[email protected]> fyi, since you have interest in > exploring a 128-bit constant pool as well. > > On Wed, Mar 17, 2021 at 5:19 AM Clemens Backes <[email protected]> > wrote: > >> Hi Dan, >> >> that sounds like an interesting idea. In fact, I considered implementing >> a Wasm constant pool for floating point constants, but SIMD code might >> benefit even more. >> Note that in Wasm code we do not have a root register (currently), so any >> access to the isolate root is a few indirections away. I am also not sure >> I fully understand how you plan to use external references to reference >> to dynamically generated constants. >> >> An alternative to allocating on the heap might be allocating in (or close >> to) the Wasm code space, and use PC-relative addressing. For security >> reasons, we should try to make the constant pool non-executable, so if we >> decide to allocate *in* the Wasm code space (instead of close by) we >> should reserve a whole page and remove execute permissions from that page. >> >> I think a good next step would be starting a little design doc (see >> https://v8.dev/docs/design-review-guidelines). I would propose to >> initially include @Zhi An Ng <[email protected]> and me, and we can add >> more people once we figure out a working solution. >> >> Thanks for working on this! >> >> -Clemens >> >> On Tue, Mar 16, 2021 at 11:07 PM Dan Weber <[email protected]> wrote: >> >>> 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 >>> [email protected] >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/d/msgid/v8-dev/CAAg-m6qF47m8fP81GoeeM4YJBaBAC8%2BY_z%3DcmanviBBeQTsD_A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> Clemens Backes >> >> Software Engineer >> >> [email protected] >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> 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. >> >> -- > -- > v8-dev mailing list > [email protected] > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CAP2LTJ1mRUt%2BR%2BM%3DX3rKFvrGVpTMG9uzdgnoCq99Qj2scyTL_A%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAP2LTJ1mRUt%2BR%2BM%3DX3rKFvrGVpTMG9uzdgnoCq99Qj2scyTL_A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3RuByF74JjbqPg_Nne055hio_ACNPNbGPSmcOY6Uj79bg%40mail.gmail.com.
