TypeSharing Bug fix #2303
Merged
TypeSharing Bug fix #2303
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
|
LGTM. Make sure to run appropriate perf tests. |
|
Thanks @rajatd
Ran perf test as well as used tracing to compare how many times we create new type. I don't see any regression. |
chakrabot
pushed a commit
that referenced
this pull request
Jan 4, 2017
Merge pull request #2303 from kunalspathak:typesharingfix See: https://microsoft.visualstudio.com/DefaultCollection/OS/_workItems?id=10058868&triage=true&_a=edit When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
chakrabot
pushed a commit
that referenced
this pull request
Jan 4, 2017
Merge pull request #2303 from kunalspathak:typesharingfix See: https://microsoft.visualstudio.com/DefaultCollection/OS/_workItems?id=10058868&triage=true&_a=edit When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
This was referenced Aug 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See: https://microsoft.visualstudio.com/DefaultCollection/OS/_workItems?id=10058868&triage=true&_a=edit
When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object.
For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object
P. Later, newCachedType evolves when properties were added on it.Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object.
In future, when we try to set same object
Pas prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacityas well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an
object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior.
Fix:
We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.