I'm far from a TurboFan expert, but I'll take a guess. Corrections from
actual experts are welcome.
Consider this function:
function sumThreeThings(point) {
return point.x + someNotInlinedFunction() + point.y;
}
Imagine the "unstable" flag doesn't exist, and you're acting as TurboFan
and optimizing that function. The feedback vectors for the loads of x and y
both contain only a single map, where the properties x and y are
represented as simple data properties (not accessors or anything fancy).
You would emit something like the following:
1. Check whether `point` has the expected map. If it's wrong, deoptimize.
2. Fetch `x` from `point` by reading at the index specified by the expected
map.
3. Call someNotInlinedFunction.
4. Check (again!) whether `point` has the expected map. If it's wrong,
deoptimize.
5. Fetch `y` from `point` by reading at the index specified by the expected
map.
Step 4 feels kind of repetitive. Could you maybe make it go away? Not
without more information. someNotInlinedFunction could do absolutely
anything including changing the map of `point`, so you do need that second
deoptimization check.
However, if you knew that the map of `point` was stable, you could omit
step 4, safe in the knowledge that some other code elsewhere would take
care of deoptimizing this function if someNotInlinedFunction caused a
change to the map of `point`. Of course this deoptimization could also be
triggered by changes to other variables that aren't `point` and just happen
to have the same shape, but that's the risk we take in exchange for the
power to remove step 4.
On Tuesday, December 31, 2019 at 1:25:50 PM UTC-8, [email protected]
wrote:
>
> Why does it matter if an object with this map has a changed map for
> optimized code? For example,
>
> ```
> var a = {x: 5, y: 5};
> var b = {x: 10, y: 10};
>
> b.z = 55; // b now has a new map. a is marked as unstable
> ```
>
> a's map is now unstable, but the map hasn't changed at all has it? The
> type of a's map hasn't changed either so why is it marked as unstable? From
> what I can tell, the only thing that has changed about the map is that a
> transition has been added to it? Why do we deoptimize code that uses this
> map?
>
> Thanks!
>
> - Jann
>
> On Tuesday, December 31, 2019 at 12:46:17 PM UTC-6, Tobias Tebbi wrote:
>>
>> As long as a map is stable, no object with this map has changed map,
>> which is a very useful property especially for optimized code. To be able
>> to exploit this in optimized code, transitioning from a previously stable
>> map will invalidate and deoptimize all optimized code that made use of the
>> map being stable up to this point.
>>
>> - Tobias
>>
>> On Tue, Dec 31, 2019 at 7:07 PM <[email protected]> wrote:
>>
>>> Thanks!
>>>
>>> What is the point of marking a map as stable? If there was a
>>> normalization isn't a new map created? So if types can't get mixed up after
>>> normalization, what is the point of marking a map as stable?
>>>
>>> - Jann
>>>
>>> On Tuesday, December 31, 2019 at 1:33:36 AM UTC-6, Leszek Swirski wrote:
>>>>
>>>> Hi,
>>>>
>>>> A stable map is one from which a transition has never been observed,
>>>> i.e. it's the leaf of the transition tree and objects with that map can be
>>>> assumed to be "stable". Perhaps "is_leaf" or
>>>> "never_transitioned_away_from"
>>>> could be alternative names but it's a subtle concept to name and naming is
>>>> hard anyway :)
>>>>
>>>> In the code you linked, I'm not 100% familiar with the reasoning but I
>>>> assume that the compiler assumes that inferred stable maps are a "safe
>>>> bet"
>>>> as far as speculation is concerned, since they're a reliable end state,
>>>> and
>>>> can be assumed to be a correct inference even if the data is unreliable.
>>>> That's mostly just a guess from the context though.
>>>>
>>>> - Leszek
>>>>
>>>> On Tue, 31 Dec 2019, 05:46 , <[email protected]> wrote:
>>>>
>>>>> What is the difference between a stable and unstable map?
>>>>>
>>>>> Context: I'm trying to understand this line of code
>>>>> https://cs.chromium.org/chromium/src/v8/src/compiler/js-native-context-specialization.cc?l=3227&rcl=4c53f9a51444393133ff303952f1296603d44ab7
>>>>>
>>>>> but can't seem to find any documentation about stable maps. Comments and
>>>>> diffs are sparse on the subject as well.
>>>>>
>>>>> --
>>>>> --
>>>>> v8-dev mailing list
>>>>> [email protected]
>>>>> 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 [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/v8-dev/d8383180-787c-4bac-8ac3-d9295d400b2c%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/v8-dev/d8383180-787c-4bac-8ac3-d9295d400b2c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>> --
>>> v8-dev mailing list
>>> [email protected]
>>> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-dev/b2064f2a-93ea-4354-ac53-150a8eb56f68%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/v8-dev/b2064f2a-93ea-4354-ac53-150a8eb56f68%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
--
v8-dev mailing list
[email protected]
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-dev/21da254d-b2f4-4021-8933-bbeadf97b73e%40googlegroups.com.
