This is expected; the optimization marker is only for code that we
*want to* optimise,
not for code that we *have* optimised. So in the normal (not
OptimizeFunctionOnNextCall) case, you'll see it transition from kNone (not
yet hot enough to optimize), to kCompileOptimizedConcurrent (i.e. start
optimising concurrently next time it's called), to kInOptimizationQueue
(currently optimising concurrently), finally back to kNone (finished
optimising and installed the optimised code). Functions check the
optimisation marker on entry, and go down a special path when it's not
kNone.
On Tue, Dec 7, 2021 at 5:12 PM Jiading Guo <zing...@gmail.com> wrote:
> Or got 'OptimizationMarker::kInOptimizationQueue' if the function
> compilation is not finished before the loop ends. I got
> 'OptimizationMarker::kNone', which looks like the compilation is not kicked
> off.
> On Tuesday, December 7, 2021 at 11:21:47 PM UTC+8 Jiading Guo wrote:
>
>> Hi Leszek,
>>
>> Thanks for your excellent explanation! Now I have a better understanding
>> of function optimization.
>>
>> However, after running the code you listed I still got `
>> OptimizationMarker::kNone`:
>>
>> - optimized code: 0x204700044001 <Code TURBOFAN>
>>
>> - optimization marker: OptimizationMarker::kNone
>> - optimization tier: OptimizationTier::kTopTier
>>
>> Is this the expected behavior? I'm expecting `
>> OptimizationMarker::kCompileOptimized` here since I have got the top
>> tier optimization, turbofan, as stated in the following `optimization
>> tier` field.
>>
>> Many Thanks,
>> Jiading
>> On Tuesday, December 7, 2021 at 9:30:58 PM UTC+8 les...@chromium.org
>> wrote:
>>
>>> There's actually a couple of things going on here.
>>>
>>> First of all, this is actually a great example of why we always tell
>>> people that we can't "just" optimize functions ahead of time. You may
>>> notice that "add" is in the --trace-opt twice; it's optimized exactly when
>>> you request it, but then as soon as that optimized code is executed, it
>>> immediately deopts due to insufficient type feedback for the add operation
>>> (this is called a "soft" deopt). You'll see the deopt/bailout if you run
>>> with --trace-deopt. Then, later, it's optimised again from being run lots
>>> of times, which is a concurrent compilation that may or may not complete
>>> before your loop ends. To get "add" properly optimized using
>>> OptimizeFunctionOnNextCall, you have to
>>>
>>> 1. Call %PrepareFunctionForOptimization(add) -- this makes sure that
>>> the add function can collect type feedback and that its bytecode is not
>>> flushed away by GC
>>> 2. Call add(1,2) -- this is a call with the correct types, two small
>>> integers, which teach it the correct type feedback for the sum
>>> 3. Call %OptimizeFunctionOnNextCall(add)
>>>
>>> Secondly, this is a bit of a printing failure -- the "code" you're
>>> seeing is on the JSFunction as you'd expect, but the "no optimized code" is
>>> actually printing as part of printing the "feedback vector" of the
>>> JSFunction. The reason is that there is only one closure (JSFunction) in
>>> one context that implements "add", which means that we can do some extra
>>> optimisations called "function context specialization"; this is the common
>>> case, but in some cases you may have JSFunctions implementing the same
>>> underlying code (e.g. function factory() { return function add(a+b) {
>>> return a+b; } } always returns a new JSFunction but one that implements
>>> the same code). For those cases, we skip the "function context
>>> specialization", and share code between these different JSFunctions by
>>> putting it on the feedback vector.
>>>
>>> Putting this together, you'll see what you originally expected by
>>> running:
>>>
>>> function factory() {
>>> return function add(a, b) { return a + b; }
>>> }
>>>
>>> // Create two closures for 'add', to turn off function context
>>> specialization.
>>> add = factory();
>>> some_other_add = factory();
>>>
>>> %PrepareFunctionForOptimization(add);
>>> // Warm up the type feedback.
>>> add(1, 2);
>>>
>>> %OptimizeFunctionOnNextCall(add);
>>> // Do the optimization.
>>> add(1, 2);
>>>
>>> // Run the loop.
>>> let sum = 0;
>>> for (let i = 0; i < 100000; i++) {
>>> sum += add(i, i);
>>> }
>>> %DebugPrint(add);
>>>
>>> - Leszek
>>>
>>> On Tuesday, December 7, 2021 at 5:45:51 AM UTC+1 zin...@gmail.com wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to mannually optimize my function [1] by
>>>> calling %OptimizeFunctionOnNextCall.
>>>>
>>>> I run `./d8 --allow-natives-syntax --trace-opt --print-opt-code
>>>> foo.js`, it seems that the function is compiled:
>>>>
>>>> [manually marking 0x1e6e082935b5 <JSFunction add (sfi =
>>>> 0x1e6e08293485)> for non-concurrent optimization]
>>>> [compiling method 0x1e6e082935b5 <JSFunction add (sfi =
>>>> 0x1e6e08293485)> (target TURBOFAN) using TurboFan]
>>>> --- Optimized code ---
>>>> optimization_id = 0
>>>> source_position = 12
>>>> kind = TURBOFAN
>>>> name = add
>>>> stack_slots = 6
>>>> compiler = turbofan
>>>> address = 0x1e6e00044001
>>>> ...
>>>>
>>>> But according to `%DebugPrint(add)` in the last line, it says:
>>>>
>>>> - code: 0x1e6e00045841 <Code TURBOFAN>
>>>> ...
>>>> - shared function info: 0x1e6e08293485 <SharedFunctionInfo add>
>>>> - no optimized code
>>>> - optimization marker: OptimizationMarker::kNone
>>>> - optimization tier: OptimizationTier::kNone
>>>>
>>>> I'm curious why it has `<Code TURBOFAN>` but `no optimized code` and
>>>> `OptimizationMarker::kNone`? Shouldn't the function be compiled with
>>>> `OptimizationMarker::kCompileOptimized`? Is there something I'm missing?
>>>> Thanks in advance!
>>>>
>>>> Regards,
>>>> Jiading
>>>>
>>>> [1] add.js:
>>>> function add(a, b) { return a + b; }
>>>> %OptimizeFunctionOnNextCall(add);
>>>> add(1, 2);
>>>> let sum = 0;
>>>> for (let i = 0; i < 100000; i++) {
>>>> sum += add(i, i);
>>>> }
>>>> %DebugPrint(add);
>>>>
>>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/v8-users/xlx22gScRNs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> v8-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/3a3fe9b6-7489-485c-81f3-a804b24e555fn%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/3a3fe9b6-7489-485c-81f3-a804b24e555fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/CAGRskv-KMPhQ-CXmUGRk8ZryoeVN82EFxnDOUiWM5zH2dwi3nw%40mail.gmail.com.
