Branch: refs/heads/webkitglib/2.42
Home: https://github.com/WebKit/WebKit
Commit: 0ebf8393b3e433292c2c281576b7578eaf64e671
https://github.com/WebKit/WebKit/commit/0ebf8393b3e433292c2c281576b7578eaf64e671
Author: Mark Lam <[email protected]>
Date: 2024-01-23 (Tue, 23 Jan 2024)
Changed paths:
A
LayoutTests/js/structuredClone/structured-clone-validation-with-big-int-expected.txt
A
LayoutTests/js/structuredClone/structured-clone-validation-with-big-int.html
M Source/JavaScriptCore/runtime/OptionsList.h
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 267815.623@safari-7617-branch (430d474531c0).
https://bugs.webkit.org/show_bug.cgi?id=265975
CloneSerializer/Deserializer's objectPool should match.
https://bugs.webkit.org/show_bug.cgi?id=265975
rdar://118868470
Reviewed by Chris Dumez and Sihui Liu
CloneSerializer and CloneDeserializer uses m_gcBuffer for multiple purposes:
1. As an object pool that ObjectReferenceTag refers back to i.e. the order
of its
entries need to be consistent between CloneSerializer and
CloneDeserializer.
2. As a keep alive buffer to protect some objects use in the serialization
effort.
Purpose (2) conflicts with purpose (1), which can lead to bugs. This patch
disambiguates
between these 2 purposes by introducing m_objectPool for purpose (1), and
m_keepAliveBuffer
for purpose (2).
Changes made:
1. Renamed m_objectPool to m_objectPoolMap.
2. Renamed m_gcBuffer to m_objectPool: for tracking the list of objects
that ObjectReferenceTag
can refer to.
3. Added m_keepAliveBuffer to CloneSerializer: for keeping miscellaneous
objects alive from the GC.
4. Renamed some method names for clarity:
CloneSerializer::checkForDuplicate -->
CloneSerializer::writeObjectReferenceIfDupe
CloneSerializer::recordObject --> CloneSerializer::addToObjectPool
CloneSerializer::startObjectInternal -->
CloneSerializer::addToObjectPoolIfNotDupe
5. Used CloneSerializer::addToObjectPoolIfNotDupe instead of the following:
CloneSerializer::startObject
CloneSerializer::startArray
CloneSerializer::startSet
CloneSerializer::startMap
The clients of addToObjectPoolIfNotDupe now indicate what object types
(indicated by their
SerializationTags) they are adding. This makes it easier to compare the
serialization and
deserialization code and make sure that they are equivalent.
This enables us to audit the type of object being added and provide a
sanity check that
it's also added on the deserializer side.
6. Introduced CloneDeserializer::addToObjectPool() so that we can tag which
object type (as
indicated by its SerializationTag) we're adding to the m_objectPool
(instead of calling
appendWithCrashOnOverflow() on it directly to add objects).
This enables us to audit the type of object being added and provide a
sanity check that
it's also added on the serializer side.
7. Removed 3 calls to m_gcBuffer.appendWithCrashOnOverflow in the BigIntTag
case in
CloneDeserializer::readBigInt(). This was a bug.
8. Removed the following calls to m_gcBuffer.appendWithCrashOnOverflow in
CloneSerializer::serialize:
a. redundant adding of the JSMap object. It was already added by
startMap(), now addToObjectPoolIfNotDupe().
b. keep alive of the JSMapIterator object. It does not need to be in
m_objectPool.
c. keep alive of a map entry value.
d. redundant adding of the JSSet object. It was already added by
startSet(), now addToObjectPoolIfNotDupe().
e. keep alive of the JSSetIterator object. It does not need to be in
m_objectPool.
These were bugs.
9. Renamed the mapObjectStartState and setObjectStartState labels in the
deserializer to match the
mapStartState and setStartState labels in the serializer. This makes it
easier to check the
equivalency of the operations in the two.
10. Added a validator (see validateSerializedResult()) in the serializer.
The validator works by running a deserialization pass on the output of
the serializer.
After that, it compares the m_objectPoolTags of the 2 passes, and their
entries should
match. This ensures that the serializer and deserializer will catch any
bugs in the
serialization / deserialization order of objects.
a. The validator is only enabled on Debug builds (not built in on
Release builds).
b. The validator is only run when
JSC::Options::validateSerializedValue() is true.
c. The validator is only run when the object graph to be serialized and
deserialized
does not contain any complicated / complex objects. "complex" here
means that
serialization of such objects cannot be validated this way.
d. The validator is only run when both serialization and deserialization
passes succeeds.
With this validator, we can now fuzz the serializer / deserializer by
creating HTML tests cases
where we build an object graph and call structureClone() on it. The
HTML test will need to have
the following comment on its 1st line:
<!-- webkit-test-runner [ jscOptions=--validateSerializedValue=true
] -->
This will enable the validator when structured cloning is done on that
object graph.
*
LayoutTests/js/structuredClone/structured-clone-validation-with-big-int-expected.txt:
Added.
*
LayoutTests/js/structuredClone/structured-clone-validation-with-big-int.html:
Added.
* Source/JavaScriptCore/runtime/OptionsList.h:
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::name):
(WTF::printInternal):
(WebCore::canBeAddedToObjectPool):
(WebCore::CloneBase::objectPoolTags const):
(WebCore::CloneBase::appendObjectPoolTag):
(WebCore::CloneSerializer::serialize):
(WebCore::CloneSerializer::sawComplexCase):
(WebCore::CloneSerializer::didSeeComplexCases const):
(WebCore::CloneSerializer::fillTransferMap):
(WebCore::CloneSerializer::writeObjectReferenceIfDupe):
(WebCore::CloneSerializer::addToObjectPool):
(WebCore::CloneSerializer::addToObjectPoolIfNotDupe):
(WebCore::CloneSerializer::dumpStringObject):
(WebCore::CloneSerializer::dumpArrayBufferView):
(WebCore::CloneSerializer::dumpIfTerminal):
(WebCore::CloneSerializer::writeObjectIndex):
(WebCore::CloneDeserializer::addToObjectPool):
(WebCore::CloneDeserializer::readBigInt):
(WebCore::CloneDeserializer::readTerminal):
(WebCore::CloneDeserializer::deserialize):
(WebCore::validateSerializedResult):
(WebCore::CloneSerializer::checkForDuplicate): Deleted.
(WebCore::CloneSerializer::recordObject): Deleted.
(WebCore::CloneSerializer::startObjectInternal): Deleted.
(WebCore::CloneSerializer::startObject): Deleted.
(WebCore::CloneSerializer::startArray): Deleted.
(WebCore::CloneSerializer::startSet): Deleted.
(WebCore::CloneSerializer::startMap): Deleted.
Canonical link: https://commits.webkit.org/267815.623@safari-7617-branch
Commit: 946a67cd427741cf62990a345d579b542782acfb
https://github.com/WebKit/WebKit/commit/946a67cd427741cf62990a345d579b542782acfb
Author: Sihui Liu <[email protected]>
Date: 2024-01-23 (Tue, 23 Jan 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 267815.625@safari-7617-branch (aa738c8a36f7).
https://bugs.webkit.org/show_bug.cgi?id=266111
SEED ☂: Video - Playback does not start - [Includes Logs] - Netflix.com
https://bugs.webkit.org/show_bug.cgi?id=266111
rdar://118775332
Reviewed by Chris Dumez and Mark Lam.
rdar://116034413 changed the serialization format of script value but
didn’t update version number. This was later fixed
by rdar://117020274, which upgraded version number to 15 and made sure data
serialized in new format contains new
version nubmer. The problem is, builds between rdar://116034413 and
rdar://117020274 could create serialized script data
in new format but with old version number 14. These data can be stored
persistently in IndexedDB database, and could not
be deserialized successfully after rdar://117020274 because they have
mismatched version number and format.
To fix this, when we see an error in deserializing data with version nubmer
14, we upgrade the version number and try
deserializing it again in new format. This patch tries deserialization
again with a new deserializer instead of using
the old deserializer because it's more complicated to revert the internal
states on a deserializer that fails.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::deserialize):
(WebCore::CloneDeserializer::takeBackingStores):
(WebCore::CloneDeserializer::takeDetachedOffscreenCanvases):
(WebCore::CloneDeserializer::takeDetachedRTCDataChannels):
(WebCore::CloneDeserializer::takeSerializedVideoChunks):
(WebCore::CloneDeserializer::takeSerializedVideoFrames):
(WebCore::CloneDeserializer::takeSerializedAudioChunks):
(WebCore::CloneDeserializer::takeSerializedAudioData):
(WebCore::CloneDeserializer::version const):
(WebCore::CloneDeserializer::upgradeVersion):
Canonical link: https://commits.webkit.org/267815.625@safari-7617-branch
Commit: 0e5a485821858b7acb5c7be586c177b15ae14a91
https://github.com/WebKit/WebKit/commit/0e5a485821858b7acb5c7be586c177b15ae14a91
Author: Dan Robson <[email protected]>
Date: 2024-01-23 (Tue, 23 Jan 2024)
Changed paths:
M Source/JavaScriptCore/dfg/DFGGraph.cpp
Log Message:
-----------
[JSC] DFG constant property load should check the validity at the main thread
This webkitglib/2.42 backport commit squashes changes from the following
three Safari commits, which add and then remove a considerable amount of
code. It's much simpler if we take the changes all together as one.
Cherry-pick [email protected] (61d47f64edd9).
https://bugs.webkit.org/show_bug.cgi?id=267134
Apply patch. rdar://120560604
[JSC] DFG constant property load should check the validity at the main
thread
https://bugs.webkit.org/show_bug.cgi?id=267134
rdar://120443399
Reviewed by Mark Lam.
Consider the following case,
CheckStructure O, S1 | S3
GetByOffset O, offset
And S1 -> S2 -> S3 structure transition happens.
By changing object concurrently with the compiler, it is possible that
we will constant fold the property with O + S2.
While we insert watchpoints into S1 and S3, we cannot notice the change
of the property in S2.
If we change O to S3 before running code, CheckStructure passes and we
can use a value loaded from O + S2.
1. If S1 and S3 transitions are both already watched by DFG / FTL, then
we do not need to care about the issue.
CheckStructure ensures that O is S1 or S3. And both has watchpoints
which fires when transition happens.
So, if we are transitioning from S1 to S2 while compiling, it
already invalidates the code.
2. If there is only one Structure (S1), then we can keep the current
optimization by checking this condition at the main thread.
CheckStructure ensures that O is S1. And this means that if the
assumption is met at the main thread, then we can continue
using this code safely. To check this condition, we added
DesiredObjectProperties, which records JSObject*, offset, value, and structure.
And at the end of compilation, in the main thread, we check this
assumption is still met.
* Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj:
* Source/JavaScriptCore/Sources.txt:
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.cpp: Added.
(JSC::DFG::DesiredObjectProperties::addLazily):
(JSC::DFG::DesiredObjectProperties::areStillValidOnMainThread):
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.h: Added.
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantProperty):
* Source/JavaScriptCore/dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cancel):
(JSC::DFG::Plan::isStillValidOnMainThread):
* Source/JavaScriptCore/dfg/DFGPlan.h:
Canonical link: https://commits.webkit.org/272448.7@safari-7618-branch
Cherry-pick 31601205b6f3. https://bugs.webkit.org/show_bug.cgi?id=267134
[JSC] DFG constant property load should check the validity at the main
thread
https://bugs.webkit.org/show_bug.cgi?id=267134
rdar://120443399
Reviewed by Mark Lam.
Consider the following case,
CheckStructure O, S1 | S3
GetByOffset O, offset
And S1 -> S2 -> S3 structure transition happens.
By changing object concurrently with the compiler, it is possible that we
will constant fold the property with O + S2.
While we insert watchpoints into S1 and S3, we cannot notice the change of
the property in S2.
If we change O to S3 before running code, CheckStructure passes and we can
use a value loaded from O + S2.
1. If S1 and S3 transitions are both already watched by DFG / FTL, then we
do not need to care about the issue.
CheckStructure ensures that O is S1 or S3. And both has watchpoints
which fires when transition happens.
So, if we are transitioning from S1 to S2 while compiling, it already
invalidates the code.
2. If there is only one Structure (S1), then we can keep the current
optimization by checking this condition at the main thread.
CheckStructure ensures that O is S1. And this means that if the
assumption is met at the main thread, then we can continue
using this code safely. To check this condition, we added
DesiredObjectProperties, which records JSObject*, offset, value, and structure.
And at the end of compilation, in the main thread, we check this
assumption is still met.
* Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj:
* Source/JavaScriptCore/Sources.txt:
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.cpp: Added.
(JSC::DFG::DesiredObjectProperties::addLazily):
(JSC::DFG::DesiredObjectProperties::areStillValidOnMainThread):
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.h: Added.
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantProperty):
* Source/JavaScriptCore/dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cancel):
(JSC::DFG::Plan::isStillValidOnMainThread):
* Source/JavaScriptCore/dfg/DFGPlan.h:
Canonical link: https://commits.webkit.org/272448.7@safari-7618-branch
Canonical link:
https://commits.webkit.org/[email protected]
Cherry-pick a8b53bc4d7b3. https://bugs.webkit.org/show_bug.cgi?id=267134
[JSC] Remove DFGDesiredObjectProperties
https://bugs.webkit.org/show_bug.cgi?id=267134
rdar://120443399
Reviewed by Mark Lam.
When we limit the structure only one, there is no way to change the
property without firing
property replacement watchpoint while keeping object's structure as
specified. So removing DFGDesiredObjectProperties.
* Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj:
* Source/JavaScriptCore/Sources.txt:
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.cpp: Removed.
* Source/JavaScriptCore/dfg/DFGDesiredObjectProperties.h: Removed.
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantProperty):
* Source/JavaScriptCore/dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cancel):
(JSC::DFG::Plan::isStillValidOnMainThread):
* Source/JavaScriptCore/dfg/DFGPlan.h:
Canonical link: https://commits.webkit.org/272448.8@safari-7618-branch
Canonical link:
https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/cf330016d67a...0e5a48582185
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
