As we discussed, I think by adding an options parameter to the SetJitCodeEventHandler function, the API should be extensible enough to handle everyone's concerns - e.g. we can then (if desired) add a flag to enumerate existing objects. I'm looking into what it takes to walk the code space post-serialization, but if I can't figure that out quickly, then I may punt on that part...
On Thu, Aug 2, 2012 at 7:22 AM, <[email protected]> wrote: > Getting close. > > @piscisaureus: I'd prefer to land siggi's patch as-is (or just slightly > modified) and build upon it with later patches. If you think this approach > is > fundamentally at odds with what node.js needs, then perhaps we can tweak > this > patch, but otherwise I'd prefer to add more functionality incrementally. > > > https://chromiumcodereview.**appspot.com/10795074/diff/** > 10021/src/serialize.cc<https://chromiumcodereview.appspot.com/10795074/diff/10021/src/serialize.cc> > File src/serialize.cc (right): > > https://chromiumcodereview.**appspot.com/10795074/diff/** > 10021/src/serialize.cc#**newcode749<https://chromiumcodereview.appspot.com/10795074/diff/10021/src/serialize.cc#newcode749> > src/serialize.cc:749: if (HeapObject::FromAddress(**address)->IsCode()) { > The deserializer is very performance sensitive, by adding this code you > are slowing down the deserialization of all objects, even though it only > applies to Code objects. The "right" way to do this is to walk the code > space after deserialization is done if a hook is installed. If you don't > want to do that in this patch, then please just leave out this case > altogether for serialized code for now. > > https://chromiumcodereview.**appspot.com/10795074/<https://chromiumcodereview.appspot.com/10795074/> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
