609005 - Never use JS_Enumerate for getting property name lists internally

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Jeff Walden [:Waldo]]

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?

Comment 1

[Brendan Eich [:brendan]]

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