IMO, this approach is a no-go. I find it very hard to believe that there
are no
regressions with this patch on the core benchmarks. It significantly bloats
the
allocation path and adds instructions to the critical path in the optimized
code
case. This is fundamentally not a wise strategy for a feature that will be
not
used by the 99.99%+ of Chrome installs.
A much better way to do this is to add the instrumentation only to
non-optimized
code and code stubs only. Crankshafted code should not have any additional
instructions in the allocation path by default. When tracking is turned on,
all
optimized should be deoptimized so that all of the allocations go through
the
instrumentation and newly generated Crankshaft code, too. If the option is
turned off again, another deopt-all should flush the instrumented optimized
code.
There would be some further issues with crankshaft-generated stubs, but you
could build a system that tracks stubs generated with Crankshaft that use
the
HAllocate instruction and invalidates them/temporarily patches them out to
tail
call new versions with instrumentation (it's not an option to leave the
stubs,
e.g. Array constructors with the instrumentation in them).
https://codereview.chromium.org/22852024/
--
--
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/groups/opt_out.
