Deoptimizations in NDB SPI

[jdduncan]

From node --trace_deopt jscrund --adapter=ndb --spi we see a list of deoptimizations in NDB SPI code:

For Indy:

• DBOperation
• DBTableHandler.getFields
• DBTableHandler.getMappedFieldCount
• execute
• stats_incr
• DBTableHandler.getColumnMetadata
• DBOperation.prepare
• allocateRowBuffer
• completeExecutedOps
• releaseKeyBuffer

For Each:

• NdbSession.getTransactionHandler
• NdbSession.buildInsertOperation
• proto.execute
• encodeRowBuffer
• DBTableHandler.get
• onExecute
• getExecIdForOperationList
• run
• attachErrorToTransaction
• exports.closeActiveTransaction
• begin

For bulk:

• QueuedAsyncCall.enqueue

[jdduncan]

http://floitsch.blogspot.com/2012/03/optimizing-for-v8-inlining.html
http://mrale.ph/blog/2011/12/18/v8-optimization-checklist.html

[jdduncan]

DBOperation: In persist(), we call DBOperation with valid tableHandler and null indexHandler. Then we come to find(), where we have a valid indexHandler and null tableHandler. This triggers the deopt. But after this DBOperation() is not deoptimized again.

getFields(): called from NdbOperation with a variety of signatures.

getMappedFieldCount(): deoptimized 3 times. One point is that "this" could be a DBTableHandler or a DBIndexHandler.

getColumnMetadata(): deoptimized 3 times. Again, "this" could be DBIndexHandler or DBTableHandler.