Hi Adam, There are several problems with what you outline. I'm skeptical that there are satisfying solutions, so I'll try to talk you out of it.
1. V8 isn't designed to be able to disable code generation: (a). Much of V8's performance relies on waiting until runtime, seeing what the runtime state of affairs is, and then generating specialized code. You could try to run the app for a while, and then create static code as if specialized at that point. The resulting application, if it can't generate code, can't react to changes at runtime. (b). V8's garbage collector relies on being able to throw code away and regenerate it later. You will need to patch the runtime system to change this assumption. 2. V8 embeds references to V8 heap-allocated objects (JavaScript objects and V8's own internal structures) in code. This requires constructing arbitrary bits of the object graph (in V8's heap), which have to ultimately be properly connected to the entire object graph. You can't really do this statically, so you will have to somehow resolve these dynamically at startup. 3. V8's code objects themselves are (relocatable) V8 heap objects. They have to be in V8's heap and look like V8 objects, and they can be pointed to by the rest of the object graph (eg, JavaScript functions, which can themselves be pointed to, etc.). V8 already has the capability to generate a snapshot of the initial heap (including code) in a compact form, that can be statically linked into the VM. You could try building off this instead of trying to generate assembler source or obj files. It would solve some of the heap graph problems, but not the performance issues. regards, Kevin -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
