Investigate the worthiness of doing ops == &js_ObjectOps in OBJ_IS_NATIVE

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
enhancement
RESOLVED WORKSFORME
9 years ago
6 years ago

People

(Reporter: Igor Bukanov, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
Currently the OBJ_IS_NATIVE macro from js/src/jsobj.h, before doing the member check on the JSObjectOps instance, compare the pointer to the instance, obj->map->ops, against &js_ObjectMaps. The idea behind this is to avoid an extra dereference of obj->map->ops for most native objects. 

But with the changes from the bug 491126 this check becomes:

  (ops) == &js_ObjectOps || !(ops)->objectMap

In this form it is no longer obvious that this first check against &js_ObjectOps is worth the troubles especially given that !(ops)->objectMap generates relatively compact code (objectMap is the first member of JSObjectMap). Yes, it avoids the dereference, but it also generates more code. So the losses from the extra penalty from the increased code size and corresponding cache misses may exceed the gain from from not doing *ops read.

We should check this. If it turned out that the first pre-check is really worth it, we should consider it for the jited code. Currently it does not use the pre-check.

Comment 1

6 years ago
This has all been changed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.