Never use JS_Enumerate for getting property name lists internally

NEW
Unassigned

Status

()

Core
JavaScript Engine
8 years ago
4 years ago

People

(Reporter: Waldo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
JS_Enumerate does a js::GetPropertyNames, then converts that AutoIdArray into a JSIdArray, which involves an extra heap allocation.  May not always be big, but it's easily-avoided waste, it needlessly cruftifies the code and executed code with another layer of conversion, and (most importantly in my view) you lose bounds-checking assertion goodness.

(There might be a use case for JS_Enumerate in internal code, but in the common cases, I don't immediately see how it's necessary.)

This was motivated by jsobj.cpp:DefineProperties, which, prior to the changeset that introduced proxies, properly used js::GetPropertyNames to get own property names.

Just brainstorming, but is there some way -- if indeed JS_Enumerate has no good uses internally -- that we could blacklist it and prevent it from being usable?  Maybe a #define JS_Enumerate(cx, obj) USE_GETPROPERTYNAMES_INSTEAD in some central location?
We could use some #ifdef'ery -- we have similar for Value vs. jsval, Class vs. JSClass, right?

This is a good bug. It's an extreme case of a general rule that could use some automated enforcing: avoid going through JS_* APIs from within the engine.

/be
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.