Proposal: Remove 9 unused DeoptimizeReason enum values (verified dead via full history search)

[ASTRA DEV]

Hi all!

I'm analyzing src/deoptimizer/deoptimize-reason.h as part of my own project (building a static analyzer for deoptimization patterns to write lint rules), and came across 9 values in DEOPTIMIZE_REASON_LIST/LAZY_DEOPTIMIZE_REASON_LIST that appear to be unused anywhere in current production code:

ConstTrackingLet, DeprecatedMap, Float16NotYetSupported, NaN, NoCache, NotASeqOneByteString, NotAStringWrapper, SuspendGeneratorIsDead, UnoptimizedCatch.

I didn't just check this superficially — for each one I confirmed two things:

(1) absence in the current HEAD across the full upstream repo (not just my local partial checkout), and (2) a full history search across diff content, to distinguish "never actually wired up" from "was used, then deliberately removed." 5 values (NaN, DeprecatedMap, NoCache, NotAStringWrapper, SuspendGeneratorIsDead) show zero historical triggers at all. The other 4 were genuinely implemented, but their sole trigger was removed in separate later commits (I found the specific commit for each — e.g. Float16NotYetSupported was retired once real Float16Array codegen support landed).

I already have a local patch ready (removes these 9 entries + updates the one real test consumer, test/cctest/test-cpu-profiler.cc), but before going through Gerrit — I wanted to ask whether this kind of cleanup is even of interest to the team, and if so, whether there's anything I should know upfront (e.g. reasons these might be intentionally kept as placeholders for future work, if that's the case and I'm missing context).

Separately, along the way I noticed that Maglev's lazy deopt path always reports kUnknown instead of the real reason (maglev-code-generator.cc), meaning --trace-deopt gives no information for lazy deopts on Maglev-compiled code — happy to write that up separately if it's of interest too.

Thanks!

[Darius Mercadier]

Hi,

>  I wanted to ask whether this kind of cleanup is even of interest to the team

Sure, please send the patch! (on Gerrit)

> whether there's anything I should know upfront

For a patch that just removes 9 lines of dead code, no need to bother. In general, the more complex the patch, the more you'll need to explain why it really improves V8 (if it's not obvious), and indeed, if you want to do fairly complex work on V8, I'd suggest reaching out to us first to make sure that you won't spend a lot of time implementing something that we have no interest in eventually merging in.

> I noticed that Maglev's lazy deopt path always reports kUnknown instead of the real reason

Eager deopts happen when a check fails, so we precisely know what failed and where, and we can easily pass this as a reason. For instance, if a Smi check fails, we can easily pass kNotASmi to the eager deopt.

Lazy deopts on the other hand are triggered from afar: some state somewhere in V8 gets invalidated, which marks the function for deoptimization, which triggers a lazy deopt when coming back to the function. In fact, a given lazy deopt point could be triggered for a number of different reasons (unlike eager deopt points, which always have a single reason). Because lazy deopts are not as local as eager deopt, it's harder to know why they were triggered. However, I think that before a lazy deopt, --trace-deopt should pretty much always print something to help you know why the lazy deopt happened:

   * either a "marking dependent code ... for deoptimization, reason: <reason>".

   * or in the case of a recursive function that lazy-deopts because it eagerly-deopted, a "bailout .. kind: eager-deopt, reason <reason>" (since eager-deopting a function will trigger lazy-deopts of all other activations on the call stack).

So I'm not sure that we really need precise DeoptimizeReasons at lazy-deopt points, since the reason should usually be somewhat easy to find out... that being said, if you have a simple patch to fix this, feel free to send it and if it's simple enough we could merge it.

Cheers,

Darius

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/71139f53-1490-4dcb-b35f-67cf0cd39599n%40googlegroups.com.