On Thu, Apr 6, 2017 at 4:38 AM, 阿炳 <[email protected]> wrote: > OK, I got it. > Thank you for explaining so many details to me. > The Code Cache V2 is exactly what I want, does this feature have a > schedule? I think 1/3 JS time in WebApp startup is quite a lot of time. >
Unfortunately, I don't really have a schedule yet. My original plan was to start working on it now; but we've decided to first handle other items first (around streaming parsing). That'll also help the page startup speed (by 'hiding' more of the parse time in idle time). But it's a different mechanism.... On Fri, Apr 7, 2017 at 5:26 PM, 阿炳 <[email protected]> wrote: > Daniel, I've read your design doc several times, have a few more questions. > 1. you said the byte code generated by ignition never change, is that > right? > Yes, that's correct. > 2. whether the byte code remains in SFI after turbofan jit generated > optimized code? or if we want to remain byte code after jit, how difficult > it will be? > The bytecode will remain. (TurboFan needs it, because if the jit-ed code needs to be "de-optimized" it will jump back to bytecode.) > 3. are there any content in byte code point to jit result after some > funtions were jited? > Not quite sure what you mean. There's several things: In addition to bytecode, there's the constant pool, which is referenced from the bytecode. E.g., any number literal, string, or function reference, etc. that's referenced in the source file. These may reference pretty much anything that can reside on the heap. Some of these have additional requirements (e.g. some strings need to be internalized ( == globally unique), which requires some sort of fix-up pass after de-serializing it. Additionally, there's e.g. the feedback vectors which gather up information ahead of time. These may reference an object's maps (i.e. the description of the actual structure of the object at runtime), which are context dependent (and therefore must not be serialized). Finally, there's a good bit of stuff 'outside' of the SharedFunctionInfos, that the code cache needs to reconstruct. (E.g. the script object). There's also references between those (e.g. a function's constant pool referencing other functions; or the Script object maintaining a list of all known SharedFunctionInfos with (stable) numeric ids). The plan is, roughly, to first serialize a 'skeleton', which contains everything referenced from the Script object, but with "empty" SharedFunctionInfos. Also, this must introduce some logic to remove all context-dependent objects. That would be a modification of the existing (de-)serializer. Then, per function, we'd store the bytecode + a serialization of the constant pool. (The first part is easy, but the second part is (another) modification of the existing (de-serializer). Then, we need some sort of 'fixup' after de-serializing a function. I don't think that'll be hard, but I'm not quite sure yet what exactly we need. -- -- 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]. For more options, visit https://groups.google.com/d/optout.
