trying to understand v8's opt/deopt strategy, is this behavior normal?

[Taylor Dondich]

So I'm building a NES(Nintendo) emulator in Javascript and I'm doing optimizations to get the emulation to run faster.  Code is located at: https://github.com/tdondich/vue-2a03-emu

So, I have done a dump of v8 activity using --trace-opt and --trace-deopt

I'm seeing a lot of deopt over and over for certain critical functions.  V8 will mark to opt, optimize, then do a soft deopt, over and over on the same functions.

So, my question is, what are good strategies to defend against this?  I'd rather it optimizes once and is good to go on these functions.

For example, I see:

[deoptimizing (DEOPT soft): begin 0x4356287660f9 <JSFunction tick (sfi = 0000435628765439)> (opt #112) @253, FP to SP delta: 152, caller sp: 0x00202c9fd7d8]

            ;;; deoptimize at <http://localhost:3000/js/nesppu.js:336:30>, Insufficient type feedback for generic named access

But documentation on insufficient type feedback for generic named access nowhere to be found.  How can I restructure my code to help avoid this?  Or the same for "Insufficent type feedback for generic named access".

So this goes on over and over, with the same depots happening on the same functions all the time (and my emu runs loops at over 3 million iterations a second).

Any insight?

Thanks!  First time going this level with V8. It's fun!

Taylor Dondich

[Isiah Meadows]

Not a V8 dev, but:

- What's the offending code triggering the opt/deopt loop look like? That should help quite a bit in understanding what's going on.

- Opt/deopt loops are engine bugs - it should never do that. V8 should figure out at some point whether to optimize or completely bail out. Feel free to report it at https://bugs.chromium.org/p/v8/issues/list.