2015-05-03 22:32:37 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
2012-03-31 08:42:20 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
|
|
|
|
* You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
2012-05-03 08:35:38 +04:00
|
|
|
#ifndef mozilla_dom_DOMJSClass_h
|
|
|
|
#define mozilla_dom_DOMJSClass_h
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2018-08-20 17:46:08 +03:00
|
|
|
#include "jsapi.h"
|
2012-03-31 08:42:20 +04:00
|
|
|
#include "jsfriendapi.h"
|
2020-09-09 01:55:38 +03:00
|
|
|
#include "js/Object.h" // JS::GetClass, JS::GetReservedSlot
|
2018-06-01 19:17:10 +03:00
|
|
|
#include "js/Wrapper.h"
|
2012-10-09 22:50:27 +04:00
|
|
|
#include "mozilla/Assertions.h"
|
2016-04-01 05:51:18 +03:00
|
|
|
#include "mozilla/Attributes.h"
|
2022-03-08 18:24:15 +03:00
|
|
|
#include "mozilla/OriginTrials.h"
|
2016-03-23 22:09:24 +03:00
|
|
|
#include "mozilla/Likely.h"
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2012-05-03 08:35:38 +04:00
|
|
|
#include "mozilla/dom/PrototypeList.h" // auto-generated
|
2019-06-13 12:01:18 +03:00
|
|
|
#include "mozilla/dom/WebIDLPrefs.h" // auto-generated
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2013-08-24 06:42:39 +04:00
|
|
|
class nsCycleCollectionParticipant;
|
2020-06-06 09:58:42 +03:00
|
|
|
class nsWrapperCache;
|
2020-11-23 19:12:19 +03:00
|
|
|
struct JSFunctionSpec;
|
|
|
|
struct JSPropertySpec;
|
2019-06-28 01:21:22 +03:00
|
|
|
struct JSStructuredCloneReader;
|
|
|
|
struct JSStructuredCloneWriter;
|
|
|
|
class nsIGlobalObject;
|
2012-09-13 00:29:30 +04:00
|
|
|
|
2012-10-25 19:01:09 +04:00
|
|
|
// All DOM globals must have a slot at DOM_PROTOTYPE_SLOT.
|
|
|
|
#define DOM_PROTOTYPE_SLOT JSCLASS_GLOBAL_SLOT_COUNT
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2013-08-21 08:21:00 +04:00
|
|
|
// Keep this count up to date with any extra global slots added above.
|
|
|
|
#define DOM_GLOBAL_SLOTS 1
|
|
|
|
|
2012-03-31 08:42:20 +04:00
|
|
|
// We use these flag bits for the new bindings.
|
2012-07-12 07:55:19 +04:00
|
|
|
#define JSCLASS_DOM_GLOBAL JSCLASS_USERBIT1
|
2012-10-09 22:50:27 +04:00
|
|
|
#define JSCLASS_IS_DOMIFACEANDPROTOJSCLASS JSCLASS_USERBIT2
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2022-05-09 23:41:05 +03:00
|
|
|
namespace mozilla::dom {
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2016-05-16 12:04:38 +03:00
|
|
|
/**
|
|
|
|
* Returns true if code running in the given JSContext is allowed to access
|
|
|
|
* [SecureContext] API on the given JSObject.
|
|
|
|
*
|
|
|
|
* [SecureContext] API exposure is restricted to use by code in a Secure
|
|
|
|
* Contexts:
|
|
|
|
*
|
|
|
|
* https://w3c.github.io/webappsec-secure-contexts/
|
|
|
|
*
|
|
|
|
* Since we want [SecureContext] exposure to depend on the privileges of the
|
|
|
|
* running code (rather than the privileges of an object's creator), this
|
2018-06-06 12:44:17 +03:00
|
|
|
* function checks to see whether the given JSContext's Realm is flagged
|
2016-05-16 12:04:38 +03:00
|
|
|
* as a Secure Context. That allows us to make sure that system principal code
|
|
|
|
* (which is marked as a Secure Context) can access Secure Context API on an
|
2018-06-06 12:44:17 +03:00
|
|
|
* object in a different realm, regardless of whether the other realm is a
|
|
|
|
* Secure Context or not.
|
2016-05-16 12:04:38 +03:00
|
|
|
*
|
2018-06-06 12:44:17 +03:00
|
|
|
* Checking the JSContext's Realm doesn't work for expanded principal
|
2016-05-16 12:04:38 +03:00
|
|
|
* globals accessing a Secure Context web page though (e.g. those used by frame
|
|
|
|
* scripts). To handle that we fall back to checking whether the JSObject came
|
|
|
|
* from a Secure Context.
|
|
|
|
*
|
|
|
|
* Note: We'd prefer this function to live in BindingUtils.h, but we need to
|
|
|
|
* call it in this header, and BindingUtils.h includes us (i.e. we'd have a
|
|
|
|
* circular dependency between headers if it lived there).
|
|
|
|
*/
|
|
|
|
inline bool IsSecureContextOrObjectIsFromSecureContext(JSContext* aCx,
|
|
|
|
JSObject* aObj) {
|
2018-06-06 12:44:17 +03:00
|
|
|
MOZ_ASSERT(!js::IsWrapper(aObj));
|
|
|
|
return JS::GetIsSecureContext(js::GetContextRealm(aCx)) ||
|
|
|
|
JS::GetIsSecureContext(js::GetNonCCWObjectRealm(aObj));
|
2016-05-16 12:04:38 +03:00
|
|
|
}
|
|
|
|
|
2013-05-04 03:29:08 +04:00
|
|
|
typedef bool (*ResolveOwnProperty)(
|
|
|
|
JSContext* cx, JS::Handle<JSObject*> wrapper, JS::Handle<JSObject*> obj,
|
2021-05-07 15:29:05 +03:00
|
|
|
JS::Handle<jsid> id,
|
|
|
|
JS::MutableHandle<mozilla::Maybe<JS::PropertyDescriptor>> desc);
|
2012-10-09 22:50:27 +04:00
|
|
|
|
2013-05-04 03:29:08 +04:00
|
|
|
typedef bool (*EnumerateOwnProperties)(JSContext* cx,
|
|
|
|
JS::Handle<JSObject*> wrapper,
|
|
|
|
JS::Handle<JSObject*> obj,
|
2019-03-13 15:33:15 +03:00
|
|
|
JS::MutableHandleVector<jsid> props);
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2016-11-04 19:41:26 +03:00
|
|
|
typedef bool (*DeleteNamedProperty)(JSContext* cx,
|
|
|
|
JS::Handle<JSObject*> wrapper,
|
|
|
|
JS::Handle<JSObject*> obj,
|
|
|
|
JS::Handle<jsid> id,
|
|
|
|
JS::ObjectOpResult& opresult);
|
|
|
|
|
2015-12-01 20:02:36 +03:00
|
|
|
// Returns true if the given global is of a type whose bit is set in
|
2023-06-06 09:51:34 +03:00
|
|
|
// aGlobalSet.
|
|
|
|
bool IsGlobalInExposureSet(JSContext* aCx, JSObject* aGlobal,
|
|
|
|
uint32_t aGlobalSet);
|
2015-12-01 20:02:36 +03:00
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
struct ConstantSpec {
|
|
|
|
const char* name;
|
|
|
|
JS::Value value;
|
|
|
|
};
|
|
|
|
|
2013-02-19 20:54:40 +04:00
|
|
|
typedef bool (*PropertyEnabled)(JSContext* cx, JSObject* global);
|
|
|
|
|
2015-12-01 20:02:33 +03:00
|
|
|
namespace GlobalNames {
|
|
|
|
// The names of our possible globals. These are the names of the actual
|
|
|
|
// interfaces, not of the global names used to refer to them in IDL [Exposed]
|
|
|
|
// annotations.
|
|
|
|
static const uint32_t Window = 1u << 0;
|
2022-03-09 23:55:36 +03:00
|
|
|
static const uint32_t DedicatedWorkerGlobalScope = 1u << 1;
|
|
|
|
static const uint32_t SharedWorkerGlobalScope = 1u << 2;
|
|
|
|
static const uint32_t ServiceWorkerGlobalScope = 1u << 3;
|
|
|
|
static const uint32_t WorkerDebuggerGlobalScope = 1u << 4;
|
2023-05-30 15:02:40 +03:00
|
|
|
static const uint32_t AudioWorkletGlobalScope = 1u << 5;
|
|
|
|
static const uint32_t PaintWorkletGlobalScope = 1u << 6;
|
|
|
|
static const uint32_t ShadowRealmGlobalScope = 1u << 7;
|
2022-03-10 18:25:17 +03:00
|
|
|
|
2023-05-30 15:02:40 +03:00
|
|
|
static constexpr uint32_t kCount = 8;
|
2015-12-01 20:02:33 +03:00
|
|
|
} // namespace GlobalNames
|
|
|
|
|
2016-03-23 22:09:24 +03:00
|
|
|
struct PrefableDisablers {
|
2015-06-16 00:22:00 +03:00
|
|
|
inline bool isEnabled(JSContext* cx, JS::Handle<JSObject*> obj) const {
|
2015-12-01 20:02:36 +03:00
|
|
|
if (nonExposedGlobals &&
|
2023-06-06 09:51:34 +03:00
|
|
|
IsGlobalInExposureSet(cx, JS::GetNonCCWObjectGlobal(obj),
|
|
|
|
nonExposedGlobals)) {
|
2015-12-01 20:02:36 +03:00
|
|
|
return false;
|
|
|
|
}
|
2019-06-13 12:01:18 +03:00
|
|
|
if (prefIndex != WebIDLPrefIndex::NoPref &&
|
|
|
|
!sWebIDLPrefs[uint16_t(prefIndex)]()) {
|
2014-02-05 22:38:17 +04:00
|
|
|
return false;
|
|
|
|
}
|
2016-05-16 12:04:38 +03:00
|
|
|
if (secureContext && !IsSecureContextOrObjectIsFromSecureContext(cx, obj)) {
|
|
|
|
return false;
|
|
|
|
}
|
2022-03-08 18:24:15 +03:00
|
|
|
if (trial != OriginTrial(0) &&
|
|
|
|
!OriginTrials::IsEnabled(cx, JS::GetNonCCWObjectGlobal(obj), trial)) {
|
|
|
|
// TODO(emilio): Perhaps reconsider the interaction between [Trial=""] and
|
|
|
|
// [Pref=""].
|
|
|
|
//
|
|
|
|
// In particular, it might be desirable to only check the trial if there
|
|
|
|
// is no pref or the pref is disabled.
|
|
|
|
return false;
|
|
|
|
}
|
2018-07-06 19:16:23 +03:00
|
|
|
if (enabledFunc && !enabledFunc(cx, JS::GetNonCCWObjectGlobal(obj))) {
|
2014-02-05 22:38:17 +04:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
2013-02-19 20:54:40 +04:00
|
|
|
}
|
|
|
|
|
2019-06-13 12:01:18 +03:00
|
|
|
// Index into the array of StaticPrefs
|
|
|
|
const WebIDLPrefIndex prefIndex;
|
2016-03-23 22:09:24 +03:00
|
|
|
|
2022-03-10 18:25:17 +03:00
|
|
|
// Bitmask of global names that we should not be exposed in.
|
|
|
|
const uint16_t nonExposedGlobals : GlobalNames::kCount;
|
|
|
|
|
2016-05-16 12:04:38 +03:00
|
|
|
// A boolean indicating whether a Secure Context is required.
|
2022-03-10 18:25:17 +03:00
|
|
|
const uint16_t secureContext : 1;
|
2016-05-16 12:04:38 +03:00
|
|
|
|
2022-03-10 18:25:17 +03:00
|
|
|
// An origin trial controlling the feature. This can be made a bitfield too if
|
|
|
|
// needed.
|
2022-03-08 18:24:15 +03:00
|
|
|
const OriginTrial trial;
|
|
|
|
|
2013-02-19 20:54:40 +04:00
|
|
|
// A function pointer to a function that can say the property is disabled
|
|
|
|
// even if "enabled" is set to true. If the pointer is null the value of
|
2016-04-21 16:48:59 +03:00
|
|
|
// "enabled" is used as-is.
|
2016-03-23 22:09:24 +03:00
|
|
|
const PropertyEnabled enabledFunc;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
struct Prefable {
|
|
|
|
inline bool isEnabled(JSContext* cx, JS::Handle<JSObject*> obj) const {
|
2018-06-01 19:17:10 +03:00
|
|
|
MOZ_ASSERT(!js::IsWrapper(obj));
|
2016-03-23 22:09:24 +03:00
|
|
|
if (MOZ_LIKELY(!disablers)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return disablers->isEnabled(cx, obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Things that can disable this set of specs. |nullptr| means "cannot be
|
|
|
|
// disabled".
|
2019-06-13 12:01:18 +03:00
|
|
|
const PrefableDisablers* const disablers;
|
2016-03-23 22:09:24 +03:00
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
// Array of specs, terminated in whatever way is customary for T.
|
|
|
|
// Null to indicate a end-of-array for Prefable, when such an
|
|
|
|
// indicator is needed.
|
2016-03-23 22:09:24 +03:00
|
|
|
const T* const specs;
|
2012-10-09 22:50:27 +04:00
|
|
|
};
|
|
|
|
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
enum PropertyType {
|
|
|
|
eStaticMethod,
|
|
|
|
eStaticAttribute,
|
|
|
|
eMethod,
|
|
|
|
eAttribute,
|
|
|
|
eUnforgeableMethod,
|
|
|
|
eUnforgeableAttribute,
|
|
|
|
eConstant,
|
|
|
|
ePropertyTypeCount
|
|
|
|
};
|
|
|
|
|
|
|
|
#define NUM_BITS_PROPERTY_INFO_TYPE 3
|
|
|
|
#define NUM_BITS_PROPERTY_INFO_PREF_INDEX 13
|
|
|
|
#define NUM_BITS_PROPERTY_INFO_SPEC_INDEX 16
|
|
|
|
|
|
|
|
struct PropertyInfo {
|
2018-05-26 15:14:10 +03:00
|
|
|
private:
|
|
|
|
// MSVC generates static initializers if we store a jsid here, even if
|
|
|
|
// PropertyInfo has a constexpr constructor. See bug 1460341 and bug 1464036.
|
|
|
|
uintptr_t mIdBits;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2018-05-26 15:14:10 +03:00
|
|
|
public:
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// One of PropertyType, will be used for accessing the corresponding Duo in
|
|
|
|
// NativePropertiesN.duos[].
|
|
|
|
uint32_t type : NUM_BITS_PROPERTY_INFO_TYPE;
|
|
|
|
// The index to the corresponding Preable in Duo.mPrefables[].
|
|
|
|
uint32_t prefIndex : NUM_BITS_PROPERTY_INFO_PREF_INDEX;
|
|
|
|
// The index to the corresponding spec in Duo.mPrefables[prefIndex].specs[].
|
|
|
|
uint32_t specIndex : NUM_BITS_PROPERTY_INFO_SPEC_INDEX;
|
2018-05-11 13:01:32 +03:00
|
|
|
|
2018-05-26 15:14:10 +03:00
|
|
|
void SetId(jsid aId) {
|
|
|
|
static_assert(sizeof(jsid) == sizeof(mIdBits),
|
|
|
|
"jsid should fit in mIdBits");
|
2022-02-13 15:01:47 +03:00
|
|
|
mIdBits = aId.asRawBits();
|
2018-05-26 15:14:10 +03:00
|
|
|
}
|
|
|
|
MOZ_ALWAYS_INLINE jsid Id() const { return jsid::fromRawBits(mIdBits); }
|
2023-03-30 15:56:36 +03:00
|
|
|
|
|
|
|
bool IsStaticMethod() const { return type == eStaticMethod; }
|
|
|
|
|
|
|
|
static int Compare(const PropertyInfo& aInfo1, const PropertyInfo& aInfo2) {
|
|
|
|
// IdToIndexComparator needs to be updated if the order here is changed!
|
|
|
|
if (MOZ_UNLIKELY(aInfo1.mIdBits == aInfo2.mIdBits)) {
|
|
|
|
MOZ_ASSERT((aInfo1.type == eMethod || aInfo1.type == eStaticMethod) &&
|
|
|
|
(aInfo2.type == eMethod || aInfo2.type == eStaticMethod));
|
|
|
|
|
|
|
|
bool isStatic1 = aInfo1.IsStaticMethod();
|
|
|
|
|
|
|
|
MOZ_ASSERT(isStatic1 != aInfo2.IsStaticMethod(),
|
|
|
|
"We shouldn't have 2 static methods with the same name!");
|
|
|
|
|
|
|
|
return isStatic1 ? -1 : 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return aInfo1.mIdBits < aInfo2.mIdBits ? -1 : 1;
|
|
|
|
}
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static_assert(
|
|
|
|
ePropertyTypeCount <= 1ull << NUM_BITS_PROPERTY_INFO_TYPE,
|
|
|
|
"We have property type count that is > (1 << NUM_BITS_PROPERTY_INFO_TYPE)");
|
|
|
|
|
|
|
|
// Conceptually, NativeProperties has seven (Prefable<T>*, PropertyInfo*) duos
|
2016-03-31 01:57:20 +03:00
|
|
|
// (where T is one of JSFunctionSpec, JSPropertySpec, or ConstantSpec), one for
|
|
|
|
// each of: static methods and attributes, methods and attributes, unforgeable
|
|
|
|
// methods and attributes, and constants.
|
|
|
|
//
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// That's 14 pointers, but in most instances most of the duos are all null, and
|
|
|
|
// there are many instances. To save space we use a variable-length type,
|
2016-03-31 01:57:20 +03:00
|
|
|
// NativePropertiesN<N>, to hold the data and getters to access it. It has N
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// actual duos (stored in duos[]), plus four bits for each of the 7 possible
|
|
|
|
// duos: 1 bit that states if that duo is present, and 3 that state that duo's
|
|
|
|
// offset (if present) in duos[].
|
2016-03-31 01:57:20 +03:00
|
|
|
//
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// All duo accesses should be done via the getters, which contain assertions
|
|
|
|
// that check we don't overrun the end of the struct. (The duo data members are
|
2016-03-31 01:57:20 +03:00
|
|
|
// public only so they can be statically initialized.) These assertions should
|
|
|
|
// never fail so long as (a) accesses to the variable-length part are guarded by
|
|
|
|
// appropriate Has*() calls, and (b) all instances are well-formed, i.e. the
|
|
|
|
// value of N matches the number of mHas* members that are true.
|
|
|
|
//
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// We store all the property ids a NativePropertiesN owns in a single array of
|
|
|
|
// PropertyInfo structs. Each struct contains an id and the information needed
|
|
|
|
// to find the corresponding Prefable for the enabled check, as well as the
|
|
|
|
// information needed to find the correct property descriptor in the
|
|
|
|
// Prefable. We also store an array of indices into the PropertyInfo array,
|
|
|
|
// sorted by bits of the corresponding jsid. Given a jsid, this allows us to
|
|
|
|
// binary search for the index of the corresponding PropertyInfo, if any.
|
|
|
|
//
|
2016-03-31 01:57:20 +03:00
|
|
|
// Finally, we define a typedef of NativePropertiesN<7>, NativeProperties, which
|
|
|
|
// we use as a "base" type used to refer to all instances of NativePropertiesN.
|
|
|
|
// (7 is used because that's the maximum valid parameter, though any other
|
|
|
|
// value 1..6 could also be used.) This is reasonable because of the
|
|
|
|
// aforementioned assertions in the getters. Upcast() is used to convert
|
|
|
|
// specific instances to this "base" type.
|
|
|
|
//
|
2020-09-24 08:07:44 +03:00
|
|
|
// An example
|
|
|
|
// ----------
|
|
|
|
// NativeProperties points to various things, and it can be hard to keep track.
|
|
|
|
// The following example shows the layout.
|
|
|
|
//
|
|
|
|
// Imagine an example interface, with:
|
|
|
|
// - 10 properties
|
|
|
|
// - 6 methods, 3 with no disablers struct, 2 sharing the same disablers
|
|
|
|
// struct, 1 using a different disablers struct
|
|
|
|
// - 4 attributes, all with no disablers
|
|
|
|
// - The property order is such that those using the same disablers structs are
|
|
|
|
// together. (This is not guaranteed, but it makes the example simpler.)
|
|
|
|
//
|
|
|
|
// Each PropertyInfo also contain indices into sMethods/sMethods_specs (for
|
|
|
|
// method infos) and sAttributes/sAttributes_specs (for attributes), which let
|
|
|
|
// them find their spec, but these are not shown.
|
|
|
|
//
|
|
|
|
// sNativeProperties sNativeProperties_ sNativeProperties_
|
|
|
|
// ---- sortedPropertyIndices[10] propertyInfos[10]
|
|
|
|
// - <several scalar fields> ---- ----
|
|
|
|
// - sortedPropertyIndices ----> <10 indices> +--> 0 info (method)
|
|
|
|
// - duos[2] ---- | 1 info (method)
|
|
|
|
// ----(methods) | 2 info (method)
|
|
|
|
// 0 - mPrefables -------> points to sMethods below | 3 info (method)
|
|
|
|
// - mPropertyInfos ------------------------------+ 4 info (method)
|
|
|
|
// 1 - mPrefables -------> points to sAttributes below 5 info (method)
|
|
|
|
// - mPropertyInfos ---------------------------------> 6 info (attr)
|
|
|
|
// ---- 7 info (attr)
|
|
|
|
// ---- 8 info (attr)
|
|
|
|
// 9 info (attr)
|
|
|
|
// ----
|
|
|
|
//
|
|
|
|
// sMethods has three entries (excluding the terminator) because there are
|
|
|
|
// three disablers structs. The {nullptr,nullptr} serves as the terminator.
|
|
|
|
// There are also END terminators within sMethod_specs; the need for these
|
|
|
|
// terminators (as opposed to a length) is deeply embedded in SpiderMonkey.
|
|
|
|
// Disablers structs are suffixed with the index of the first spec they cover.
|
|
|
|
//
|
|
|
|
// sMethods sMethods_specs
|
|
|
|
// ---- ----
|
|
|
|
// 0 - nullptr +----> 0 spec
|
|
|
|
// - specs ----------------------+ 1 spec
|
|
|
|
// 1 - disablers ---> disablers4 2 spec
|
|
|
|
// - specs ------------------------+ 3 END
|
|
|
|
// 2 - disablers ---> disablers7 +--> 4 spec
|
|
|
|
// - specs ----------------------+ 5 spec
|
|
|
|
// 3 - nullptr | 6 END
|
|
|
|
// - nullptr +----> 7 spec
|
|
|
|
// ---- 8 END
|
|
|
|
//
|
|
|
|
// sAttributes has a single entry (excluding the terminator) because all of the
|
|
|
|
// specs lack disablers.
|
|
|
|
//
|
|
|
|
// sAttributes sAttributes_specs
|
|
|
|
// ---- ----
|
|
|
|
// 0 - nullptr +----> 0 spec
|
|
|
|
// - specs ----------------------+ 1 spec
|
|
|
|
// 1 - nullptr 2 spec
|
|
|
|
// - nullptr 3 spec
|
|
|
|
// ---- 4 END
|
|
|
|
// ----
|
2016-03-31 01:57:20 +03:00
|
|
|
template <int N>
|
|
|
|
struct NativePropertiesN {
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// Duo structs are stored in the duos[] array, and each element in the array
|
|
|
|
// could require a different T. Therefore, we can't use the correct type for
|
|
|
|
// mPrefables. Instead we use void* and cast to the correct type in the
|
|
|
|
// getters.
|
|
|
|
struct Duo {
|
2016-03-31 01:57:20 +03:00
|
|
|
const /*Prefable<const T>*/ void* const mPrefables;
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
PropertyInfo* const mPropertyInfos;
|
2016-03-31 01:57:20 +03:00
|
|
|
};
|
|
|
|
|
2016-07-09 00:39:53 +03:00
|
|
|
constexpr const NativePropertiesN<7>* Upcast() const {
|
2016-03-31 01:57:20 +03:00
|
|
|
return reinterpret_cast<const NativePropertiesN<7>*>(this);
|
|
|
|
}
|
2014-07-04 17:02:10 +04:00
|
|
|
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
const PropertyInfo* PropertyInfos() const { return duos[0].mPropertyInfos; }
|
|
|
|
|
2016-03-31 01:57:20 +03:00
|
|
|
#define DO(SpecT, FieldName) \
|
|
|
|
public: \
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
/* The bitfields indicating the duo's presence and (if present) offset. */ \
|
2016-03-31 01:57:20 +03:00
|
|
|
const uint32_t mHas##FieldName##s : 1; \
|
|
|
|
const uint32_t m##FieldName##sOffset : 3; \
|
2018-11-30 13:46:48 +03:00
|
|
|
\
|
2016-03-31 01:57:20 +03:00
|
|
|
private: \
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
const Duo* FieldName##sDuo() const { \
|
2016-03-31 01:57:20 +03:00
|
|
|
MOZ_ASSERT(Has##FieldName##s()); \
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
return &duos[m##FieldName##sOffset]; \
|
2016-03-31 01:57:20 +03:00
|
|
|
} \
|
2018-11-30 13:46:48 +03:00
|
|
|
\
|
2016-03-31 01:57:20 +03:00
|
|
|
public: \
|
|
|
|
bool Has##FieldName##s() const { return mHas##FieldName##s; } \
|
|
|
|
const Prefable<const SpecT>* FieldName##s() const { \
|
|
|
|
return static_cast<const Prefable<const SpecT>*>( \
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
FieldName##sDuo()->mPrefables); \
|
2016-03-31 01:57:20 +03:00
|
|
|
} \
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
PropertyInfo* FieldName##PropertyInfos() const { \
|
|
|
|
return FieldName##sDuo()->mPropertyInfos; \
|
2016-03-31 01:57:20 +03:00
|
|
|
}
|
2014-07-04 17:02:10 +04:00
|
|
|
|
2016-03-31 01:57:20 +03:00
|
|
|
DO(JSFunctionSpec, StaticMethod)
|
|
|
|
DO(JSPropertySpec, StaticAttribute)
|
|
|
|
DO(JSFunctionSpec, Method)
|
|
|
|
DO(JSPropertySpec, Attribute)
|
|
|
|
DO(JSFunctionSpec, UnforgeableMethod)
|
|
|
|
DO(JSPropertySpec, UnforgeableAttribute)
|
|
|
|
DO(ConstantSpec, Constant)
|
2014-07-04 17:02:10 +04:00
|
|
|
|
2016-03-31 01:57:20 +03:00
|
|
|
#undef DO
|
2015-03-28 03:44:44 +03:00
|
|
|
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// The index to the iterator method in MethodPropertyInfos() array.
|
|
|
|
const int16_t iteratorAliasMethodIndex;
|
|
|
|
// The number of PropertyInfo structs that the duos manage. This is the total
|
|
|
|
// count across all duos.
|
|
|
|
const uint16_t propertyInfoCount;
|
|
|
|
// The sorted indices array from sorting property ids, which will be used when
|
|
|
|
// we binary search for a property.
|
|
|
|
uint16_t* sortedPropertyIndices;
|
|
|
|
|
|
|
|
const Duo duos[N];
|
2012-10-09 22:50:27 +04:00
|
|
|
};
|
|
|
|
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
// Ensure the struct has the expected size. The 8 is for the bitfields plus
|
|
|
|
// iteratorAliasMethodIndex and idsLength; the rest is for the idsSortedIndex,
|
|
|
|
// and duos[].
|
2016-03-31 01:57:20 +03:00
|
|
|
static_assert(sizeof(NativePropertiesN<1>) == 8 + 3 * sizeof(void*), "1 size");
|
Bug 1348099 part 1 - Binary search property id when resolve DOM Xrays own property. r=bz
Currently we resolve a property by iterating every prefable and check whether it
is enabled. If it is, we linear search the ids that it manages. This patch
changes that to binary searching to find whether the id being resolved is
present first, and checking whether its prefable is enabled only when we find
it. This improves the performance of property resolution, especially when the
property is not present.
The patch stores all the property ids a NativePropertiesN owns in a single array
of PropertyInfo structs. Each struct contains an id and the information needed
to find the corresponding Prefable for the enabled check, as well as the
information needed to find the correct property descriptor in the Prefable. We
also store an array of indices into the PropertyInfo array, sorted by bits of
the corresponding jsid. Given a jsid, this allows us to binary search for the
index of the corresponding PropertyInfo, if any. The index array requires 2
bytes for each property, which is ~20k across all our bindings. The extra
information stored in each PropertyInfo requires 4 bytes for each property,
which is about 40k across all our bindings in 32-bit builds, or 80k in 64-bit
builds due to alignment requirements on PropertyInfo. However we save a bit of
memory from changing NativePropertiesN's trios to duos.
The array of unsorted ids is kept because XrayOwnPropertyKeys() includes only
properties that are enabled. Without it, we will need to check every single
property to know whether its prefable is enabled or not, which is inefficient.
With this patch, initializing property ids takes longer because of the sorting.
I measured also insertion sort because I thought the ids should be nearly sorted
as they are generated sequentially at run time, but that's not the case and
NS_QuickSort() runs faster.
MozReview-Commit-ID: Lc4Z1ui3t0o
--HG--
extra : rebase_source : 314efe467a14428c57f90af2ecc0ec5c47a31993
2017-06-12 07:13:38 +03:00
|
|
|
static_assert(sizeof(NativePropertiesN<2>) == 8 + 5 * sizeof(void*), "2 size");
|
|
|
|
static_assert(sizeof(NativePropertiesN<3>) == 8 + 7 * sizeof(void*), "3 size");
|
|
|
|
static_assert(sizeof(NativePropertiesN<4>) == 8 + 9 * sizeof(void*), "4 size");
|
|
|
|
static_assert(sizeof(NativePropertiesN<5>) == 8 + 11 * sizeof(void*), "5 size");
|
|
|
|
static_assert(sizeof(NativePropertiesN<6>) == 8 + 13 * sizeof(void*), "6 size");
|
|
|
|
static_assert(sizeof(NativePropertiesN<7>) == 8 + 15 * sizeof(void*), "7 size");
|
2016-03-31 01:57:20 +03:00
|
|
|
|
|
|
|
// The "base" type.
|
|
|
|
typedef NativePropertiesN<7> NativeProperties;
|
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
struct NativePropertiesHolder {
|
|
|
|
const NativeProperties* regular;
|
|
|
|
const NativeProperties* chromeOnly;
|
2021-05-07 16:57:24 +03:00
|
|
|
// Points to a static bool that's set to true once the regular and chromeOnly
|
|
|
|
// NativeProperties have been inited. This is a pointer to a bool instead of
|
|
|
|
// a bool value because NativePropertiesHolder is stored by value in
|
|
|
|
// a static const NativePropertyHooks.
|
|
|
|
bool* inited;
|
2012-10-09 22:50:27 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
// Helper structure for Xrays for DOM binding objects. The same instance is used
|
|
|
|
// for instances, interface objects and interface prototype objects of a
|
|
|
|
// specific interface.
|
2012-03-31 08:42:20 +04:00
|
|
|
struct NativePropertyHooks {
|
2012-10-09 22:50:27 +04:00
|
|
|
// The hook to call for resolving indexed or named properties. May be null if
|
|
|
|
// there can't be any.
|
|
|
|
ResolveOwnProperty mResolveOwnProperty;
|
|
|
|
// The hook to call for enumerating indexed or named properties. May be null
|
|
|
|
// if there can't be any.
|
|
|
|
EnumerateOwnProperties mEnumerateOwnProperties;
|
2016-11-04 19:41:26 +03:00
|
|
|
// The hook to call to delete a named property. May be null if there are no
|
|
|
|
// named properties or no named property deleter. On success (true return)
|
|
|
|
// the "found" argument will be set to true if there was in fact such a named
|
|
|
|
// property and false otherwise. If it's set to false, the caller is expected
|
|
|
|
// to proceed with whatever deletion behavior it would have if there were no
|
|
|
|
// named properties involved at all (i.e. if the hook were null). If it's set
|
|
|
|
// to true, it will indicate via opresult whether the delete actually
|
|
|
|
// succeeded.
|
|
|
|
DeleteNamedProperty mDeleteNamedProperty;
|
2012-10-09 22:50:27 +04:00
|
|
|
|
|
|
|
// The property arrays for this interface.
|
|
|
|
NativePropertiesHolder mNativeProperties;
|
|
|
|
|
|
|
|
// This will be set to the ID of the interface prototype object for the
|
|
|
|
// interface, if it has one. If it doesn't have one it will be set to
|
|
|
|
// prototypes::id::_ID_Count.
|
|
|
|
prototypes::ID mPrototypeID;
|
|
|
|
|
|
|
|
// This will be set to the ID of the interface object for the interface, if it
|
|
|
|
// has one. If it doesn't have one it will be set to
|
|
|
|
// constructors::id::_ID_Count.
|
|
|
|
constructors::ID mConstructorID;
|
|
|
|
|
2016-10-11 01:16:26 +03:00
|
|
|
// The JSClass to use for expandos on our Xrays. Can be null, in which case
|
|
|
|
// Xrays will use a default class of their choice.
|
|
|
|
const JSClass* mXrayExpandoClass;
|
2012-10-09 22:50:27 +04:00
|
|
|
};
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2016-03-23 21:54:38 +03:00
|
|
|
enum DOMObjectType : uint8_t {
|
2012-10-09 22:50:27 +04:00
|
|
|
eInstance,
|
2014-09-15 18:51:40 +04:00
|
|
|
eGlobalInstance,
|
2012-10-09 22:50:27 +04:00
|
|
|
eInterface,
|
2014-09-09 17:19:10 +04:00
|
|
|
eInterfacePrototype,
|
2014-09-15 18:51:40 +04:00
|
|
|
eGlobalInterfacePrototype,
|
2023-01-10 01:19:53 +03:00
|
|
|
eNamespace,
|
2014-09-09 17:19:10 +04:00
|
|
|
eNamedPropertiesObject
|
2012-03-31 08:42:20 +04:00
|
|
|
};
|
|
|
|
|
2014-09-15 18:51:40 +04:00
|
|
|
inline bool IsInstance(DOMObjectType type) {
|
|
|
|
return type == eInstance || type == eGlobalInstance;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool IsInterfacePrototype(DOMObjectType type) {
|
|
|
|
return type == eInterfacePrototype || type == eGlobalInterfacePrototype;
|
|
|
|
}
|
|
|
|
|
2016-07-27 18:05:36 +03:00
|
|
|
typedef JSObject* (*AssociatedGlobalGetter)(JSContext* aCx,
|
|
|
|
JS::Handle<JSObject*> aObj);
|
2014-09-09 17:19:10 +04:00
|
|
|
|
2016-07-09 07:19:52 +03:00
|
|
|
typedef JSObject* (*ProtoGetter)(JSContext* aCx);
|
|
|
|
|
2013-05-02 07:44:11 +04:00
|
|
|
/**
|
2016-07-09 07:19:52 +03:00
|
|
|
* Returns a handle to the relevant WebIDL prototype object for the current
|
|
|
|
* compartment global (which may be a handle to null on out of memory). Once
|
|
|
|
* allocated, the prototype object is guaranteed to exist as long as the global
|
|
|
|
* does, since the global traces its array of WebIDL prototypes and
|
|
|
|
* constructors.
|
2013-05-02 07:44:11 +04:00
|
|
|
*/
|
2016-07-09 07:19:52 +03:00
|
|
|
typedef JS::Handle<JSObject*> (*ProtoHandleGetter)(JSContext* aCx);
|
2012-09-26 18:17:46 +04:00
|
|
|
|
2019-06-28 01:21:22 +03:00
|
|
|
/**
|
|
|
|
* Serializes a WebIDL object for structured cloning. aObj may not be in the
|
|
|
|
* compartment of aCx in cases when we were working with a cross-compartment
|
|
|
|
* wrapper. aObj is expected to be an object of the DOMJSClass that we got the
|
|
|
|
* serializer from.
|
|
|
|
*/
|
|
|
|
typedef bool (*WebIDLSerializer)(JSContext* aCx,
|
|
|
|
JSStructuredCloneWriter* aWriter,
|
|
|
|
JS::Handle<JSObject*> aObj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Deserializes a WebIDL object from a structured clone serialization.
|
|
|
|
*/
|
|
|
|
typedef JSObject* (*WebIDLDeserializer)(JSContext* aCx,
|
|
|
|
nsIGlobalObject* aGlobal,
|
|
|
|
JSStructuredCloneReader* aReader);
|
|
|
|
|
2020-06-06 09:58:42 +03:00
|
|
|
typedef nsWrapperCache* (*WrapperCacheGetter)(JS::Handle<JSObject*> aObj);
|
|
|
|
|
2014-06-19 00:19:19 +04:00
|
|
|
// Special JSClass for reflected DOM objects.
|
|
|
|
struct DOMJSClass {
|
|
|
|
// It would be nice to just inherit from JSClass, but that precludes pure
|
|
|
|
// compile-time initialization of the form |DOMJSClass = {...};|, since C++
|
|
|
|
// only allows brace initialization for aggregate/POD types.
|
2019-08-14 20:15:15 +03:00
|
|
|
const JSClass mBase;
|
2014-06-19 00:19:19 +04:00
|
|
|
|
2012-05-22 17:46:20 +04:00
|
|
|
// A list of interfaces that this object implements, in order of decreasing
|
|
|
|
// derivedness.
|
2012-12-13 20:01:00 +04:00
|
|
|
const prototypes::ID mInterfaceChain[MAX_PROTOTYPE_CHAIN_LENGTH];
|
2012-05-22 17:46:20 +04:00
|
|
|
|
|
|
|
// We store the DOM object in reserved slot with index DOM_OBJECT_SLOT or in
|
|
|
|
// the proxy private if we use a proxy object.
|
|
|
|
// Sometimes it's an nsISupports and sometimes it's not; this class tells
|
|
|
|
// us which it is.
|
|
|
|
const bool mDOMObjectIsISupports;
|
|
|
|
|
|
|
|
const NativePropertyHooks* mNativeHooks;
|
2012-09-26 22:12:15 +04:00
|
|
|
|
2016-07-27 18:05:36 +03:00
|
|
|
// A callback to find the associated global for our C++ object. Note that
|
|
|
|
// this is used in cases when that global is _changing_, so it will not match
|
|
|
|
// the global of the JSObject* passed in to this function!
|
|
|
|
AssociatedGlobalGetter mGetAssociatedGlobal;
|
2014-09-09 17:19:10 +04:00
|
|
|
ProtoHandleGetter mGetProto;
|
2012-09-26 18:17:46 +04:00
|
|
|
|
2015-09-14 17:08:02 +03:00
|
|
|
// This stores the CC participant for the native, null if this class does not
|
|
|
|
// implement cycle collection or if it inherits from nsISupports (we can get
|
|
|
|
// the CC participant by QI'ing in that case).
|
2012-09-26 22:12:15 +04:00
|
|
|
nsCycleCollectionParticipant* mParticipant;
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2019-06-28 01:21:22 +03:00
|
|
|
// The serializer for this class if the relevant object is [Serializable].
|
|
|
|
// Null otherwise.
|
|
|
|
WebIDLSerializer mSerializer;
|
|
|
|
|
2020-06-06 09:58:42 +03:00
|
|
|
// A callback to get the wrapper cache for C++ objects that don't inherit from
|
|
|
|
// nsISupports, or null.
|
|
|
|
WrapperCacheGetter mWrapperCacheGetter;
|
|
|
|
|
2012-03-31 08:42:20 +04:00
|
|
|
static const DOMJSClass* FromJSClass(const JSClass* base) {
|
|
|
|
MOZ_ASSERT(base->flags & JSCLASS_IS_DOMJSCLASS);
|
|
|
|
return reinterpret_cast<const DOMJSClass*>(base);
|
|
|
|
}
|
|
|
|
|
2019-08-14 20:24:59 +03:00
|
|
|
const JSClass* ToJSClass() const { return &mBase; }
|
2012-03-31 08:42:20 +04:00
|
|
|
};
|
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
// Special JSClass for DOM interface and interface prototype objects.
|
|
|
|
struct DOMIfaceAndProtoJSClass {
|
2019-08-14 20:15:15 +03:00
|
|
|
// It would be nice to just inherit from JSClass, but that precludes pure
|
2012-10-09 22:50:27 +04:00
|
|
|
// compile-time initialization of the form
|
|
|
|
// |DOMJSInterfaceAndPrototypeClass = {...};|, since C++ only allows brace
|
|
|
|
// initialization for aggregate/POD types.
|
2019-08-14 20:15:15 +03:00
|
|
|
const JSClass mBase;
|
2012-10-09 22:50:27 +04:00
|
|
|
|
2023-01-10 01:19:53 +03:00
|
|
|
// Either eInterface, eNamespace, eInterfacePrototype,
|
|
|
|
// eGlobalInterfacePrototype or eNamedPropertiesObject.
|
2016-08-04 04:32:07 +03:00
|
|
|
DOMObjectType mType; // uint8_t
|
2012-10-09 22:50:27 +04:00
|
|
|
|
2016-08-04 04:32:07 +03:00
|
|
|
const prototypes::ID mPrototypeID; // uint16_t
|
2016-03-23 21:54:38 +03:00
|
|
|
const uint32_t mDepth;
|
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
const NativePropertyHooks* mNativeHooks;
|
|
|
|
|
2014-09-09 17:19:10 +04:00
|
|
|
ProtoGetter mGetParentProto;
|
|
|
|
|
2012-10-09 22:50:27 +04:00
|
|
|
static const DOMIfaceAndProtoJSClass* FromJSClass(const JSClass* base) {
|
|
|
|
MOZ_ASSERT(base->flags & JSCLASS_IS_DOMIFACEANDPROTOJSCLASS);
|
|
|
|
return reinterpret_cast<const DOMIfaceAndProtoJSClass*>(base);
|
|
|
|
}
|
|
|
|
|
2019-08-14 20:24:59 +03:00
|
|
|
const JSClass* ToJSClass() const { return &mBase; }
|
2012-10-09 22:50:27 +04:00
|
|
|
};
|
|
|
|
|
2023-06-20 15:16:00 +03:00
|
|
|
// Special JSClass for DOM interface objects.
|
|
|
|
struct DOMIfaceJSClass : public DOMIfaceAndProtoJSClass {
|
|
|
|
// Boolean indicating whether this object wants a @@hasInstance property
|
|
|
|
// pointing to InterfaceHasInstance defined on it. Only ever true for the
|
|
|
|
// eInterface case.
|
|
|
|
bool wantsInterfaceHasInstance;
|
|
|
|
|
|
|
|
// The value to return for Function.prototype.toString on this interface
|
|
|
|
// object.
|
|
|
|
const char* mFunToString;
|
|
|
|
|
|
|
|
static const DOMIfaceJSClass* FromJSClass(const JSClass* base) {
|
|
|
|
const DOMIfaceAndProtoJSClass* clazz =
|
|
|
|
DOMIfaceAndProtoJSClass::FromJSClass(base);
|
|
|
|
MOZ_ASSERT(clazz->mType == eInterface || clazz->mType == eNamespace);
|
|
|
|
return static_cast<const DOMIfaceJSClass*>(clazz);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-03-22 21:04:09 +04:00
|
|
|
class ProtoAndIfaceCache;
|
2013-11-19 23:28:09 +04:00
|
|
|
|
2016-05-14 03:21:40 +03:00
|
|
|
inline bool DOMGlobalHasProtoAndIFaceCache(JSObject* global) {
|
2022-12-02 18:12:12 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(JS::GetClass(global)->flags & JSCLASS_DOM_GLOBAL);
|
2012-06-19 04:04:38 +04:00
|
|
|
// This can be undefined if we GC while creating the global
|
2020-09-09 01:55:38 +03:00
|
|
|
return !JS::GetReservedSlot(global, DOM_PROTOTYPE_SLOT).isUndefined();
|
2012-06-19 04:04:38 +04:00
|
|
|
}
|
|
|
|
|
2016-05-14 03:21:40 +03:00
|
|
|
inline bool HasProtoAndIfaceCache(JSObject* global) {
|
2020-09-09 01:55:38 +03:00
|
|
|
if (!(JS::GetClass(global)->flags & JSCLASS_DOM_GLOBAL)) {
|
2016-05-14 03:21:40 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return DOMGlobalHasProtoAndIFaceCache(global);
|
|
|
|
}
|
|
|
|
|
2014-03-22 21:04:09 +04:00
|
|
|
inline ProtoAndIfaceCache* GetProtoAndIfaceCache(JSObject* global) {
|
2022-12-02 18:12:12 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(JS::GetClass(global)->flags & JSCLASS_DOM_GLOBAL);
|
2014-03-22 21:04:09 +04:00
|
|
|
return static_cast<ProtoAndIfaceCache*>(
|
2020-09-09 01:55:38 +03:00
|
|
|
JS::GetReservedSlot(global, DOM_PROTOTYPE_SLOT).toPrivate());
|
2012-03-31 08:42:20 +04:00
|
|
|
}
|
|
|
|
|
2022-05-09 23:41:05 +03:00
|
|
|
} // namespace mozilla::dom
|
2012-03-31 08:42:20 +04:00
|
|
|
|
2012-05-03 08:35:38 +04:00
|
|
|
#endif /* mozilla_dom_DOMJSClass_h */
|