Cleanup js::LookupProperty and friends
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: tcampbell, Assigned: tcampbell)
Details
Attachments
(7 files, 5 obsolete files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
The current js::LookupPropertyPure code is a little hard to understand all the edges cases it takes into account and this can be simplified by adding specialized methods to PropertyResult and adding more comments.
| Assignee | ||
Comment 1•4 years ago
|
||
This is a specialized version of setOutOfRange that stores an extra flag to
indicate that the property id is a special TypedArrayIndex (a String that
converts to a Number and back exactly). This lets the caller know that the
prototype chain should not be searched without needing to repeat the
conversion operation.
Depends on D105884
| Assignee | ||
Comment 2•4 years ago
|
||
Depends on D105885
| Assignee | ||
Comment 3•4 years ago
|
||
The Result<Maybe<T>> construct isn't clearer than our usual return-bool
convention so simplify things by using an out-param. This should also
generate better machine code.
Depends on D105886
| Assignee | ||
Comment 4•4 years ago
|
||
Add documentation for some of the edge cases. Move the setNotFound case
within the per-type blocks since accidentally returning this would be a
serious issues and return false as the default is much safer.
Depends on D105887
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 5•4 years ago
|
||
In future, we should really better structure the TypedArrayObject and ArrayObject special handling throughout the engine. They are truly exotic object behaviours and even if we choose to inline the behaviour instead of using an ObjectOps/ClassOps hooks, we need a better way to organize this code.
Updated•4 years ago
|
| Assignee | ||
Comment 6•4 years ago
|
||
Instead use explicit isFound/isNotFound accessors for clarity.
Depends on D105885
| Assignee | ||
Comment 7•4 years ago
|
||
I'll expand the scope of this bug to unify LookupPropertyInline with LookupPropertyPure and cleaning up other related methods.
Updated•4 years ago
|
| Assignee | ||
Comment 8•4 years ago
|
||
Use single implementation of NativeLookupOwnPropertyInline for:
- NativeLookupOwnPropertyNoResolve
- NativeLookupOwnProperty
- LookupOwnPropertyPure
Use single implementation of NativeLookupPropertyInline for:
- LookupPropertyPure
Use ClassMayResolveId instead of just checking for a resolve hook. This is
what the JITs already do.
Remove the TypedObject check from LookupOwnPropertyPure since none of the
callers would have handled it any different than the unknown case.
Replace a few checks for is<NativeObject> in lookup code with a check for the
lookupProperty hook instead. This more accurate and is still a simple lookup
on the JSClass.
Depends on D105885
Updated•4 years ago
|
| Assignee | ||
Comment 9•4 years ago
|
||
Depends on D105885
| Assignee | ||
Comment 10•4 years ago
|
||
This now uses ClassMayResolveId instead of just checking for a resolve
hook. This changes a small number of cases that were fast paths in the VM to
now will invoke the mayResolve hook where they didn't before. This adds a
small penalty when the hook returns false, but in that case we were retrying
the full operation, running resolve hook and defining a property. This
reduces the number of similar implementations of lookup.
Depends on D106235
| Assignee | ||
Comment 11•4 years ago
|
||
Depends on D106236
| Assignee | ||
Comment 12•4 years ago
|
||
These only support NativeObjects, so rename for clarity.
Depends on D106237
| Assignee | ||
Comment 13•4 years ago
|
||
Merge the following implementations:
- NativeLookupOwnPropertyInline
- NativeLookupOwnPropertyNoResolve
- LookupOwnPropertyPure
This introduces a mayResolve check where there was not before, but the only
use that would have observed that is LookupNameNoGC which works on
environments that have no resolve hooks to being with. As a result, this is
simply removing duplicate code.
We no longer support anything with a lookupProperty hook. Previously the JITs
would tolerate them, but in practice do nothing useful. One case was for
environment objects which triggered this during SetProp but would later
abort. The other case was TypedObjects which are no longer meaningully
supported by the JITs and are treated no differently than unknown.
NOTE: An earlier patch moved some uses to LookupOwnPropertyPure already and
the justification for why the extra mayResolve hook is fine is listed
there.
Depends on D106238
| Assignee | ||
Comment 14•4 years ago
|
||
Combine implementation of:
- NativeLookupPropertyInline
- LookupPropertyPure
Instead of checking for is<NativeObject>, check for a lookupProperty hook
which is more indicative of what we are worried about.
Depends on D106239
Updated•4 years ago
|
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
| bugherder | ||
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
| bugherder | ||
| Assignee | ||
Updated•4 years ago
|
Description
•