- Node.js Version: 8.0.0-pre (v8 5.6.326.55)
- OS: Windows 7 x64
- Scope: v8
Checking different opt/deopt cases, I often stumble on this scheme (the function name is just a one example):
[marking 0000011AAAC5ACA9 <JS Function fs.readFile (SharedFunctionInfo 0000011AAAC31C29)> for optimized recompilation, reason: hot and stable, ICs with typeinfo: 25/39 (64%), generic ICs: 0/39 (0%)]
[compiling method 0000011AAAC5ACA9 <JS Function fs.readFile (SharedFunctionInfo 0000011AAAC31C29)> using Crankshaft]
[optimizing 0000011AAAC5ACA9 <JS Function fs.readFile (SharedFunctionInfo 0000011AAAC31C29)> - took 1.120, 2.973, 0.862 ms]
[completed optimizing 0000011AAAC5ACA9 <JS Function fs.readFile (SharedFunctionInfo 0000011AAAC31C29)>]
...
[deoptimizer unlinked: fs.readFile / 11aaac5aca9]
[evicting entry from optimizing code map (deoptimized code) for 0000011AAAC31C29 <SharedFunctionInfo fs.readFile>]
That's all, just these 6 messages concerning the tested function.
Do the last two messages mean the function is deoptimized? If so, how can we detect the cause? If not, what do they mean?
// cc @nodejs/v8
Checking different opt/deopt cases, I often stumble on this scheme (the function name is just a one example):
That's all, just these 6 messages concerning the tested function.
Do the last two messages mean the function is deoptimized? If so, how can we detect the cause? If not, what do they mean?
// cc @nodejs/v8